You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(6) |
2
(3) |
3
|
4
(3) |
5
(10) |
6
(4) |
7
(5) |
|
8
(1) |
9
(3) |
10
(11) |
11
(18) |
12
(13) |
13
(4) |
14
(11) |
|
15
(12) |
16
(6) |
17
(1) |
18
(13) |
19
(14) |
20
(12) |
21
(3) |
|
22
(17) |
23
(18) |
24
(17) |
25
(24) |
26
(15) |
27
(7) |
28
(23) |
|
29
(31) |
|
|
|
|
|
|
|
From: Tom H. <th...@cy...> - 2004-02-19 23:59:05
|
In message <ICE...@at...>
"Chris January" <ch...@at...> wrote:
> > * we're also likely to be officially supporting other operating
> > systems (starting with Doug's FreeBSD port), so make sure that
> > any OS/library dependencies are factored out
>
> The code I've already written depends on Sys V IPC shm support but if
> gdbstub is used instead then this should be pretty OS neutral.
If you do wind up sticking with shared memory I would seriously
recommend using mmaped memory if possible rather than Sys V shared
memory as it's much less likely to cause problems in my experience.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Chris J. <ch...@at...> - 2004-02-19 23:09:50
|
> > Hi all, > > > > I've been working on adding Valgrind support to GDB. I've written a GDB > > target that allows you to debug a process running under Valgrind. The > > threads emulated by vg_scheduler.c show up as normal threads > and a special > > thread 1 represents the real state of the process. For the > implementation I > > moved the VG_(threads) array to a shared memory region which > can be accessed > > by GDB to obtain the state of the emulated threads. I also > added support for > > single step and breakpoints to Valgrind. > > The patches to Valgrind 2.0.0 and GDB 6.0 are available on my website > > (www.atomice.com). > > I was hoping that these patches could lead to an official > method of exposing > > the state of Valgrind's emulated threads to external debuggers. > Inevitably > > this would mean designing some kind of fixed structure > containing a subset > > of the thread state that wouldn't change from version to > version. At present > > the patches I've written are sensitive to changed in the ThreadState > > structure. > > I think it would also be useful once an external debugger > interface is in > > place to add an option to skins such as memcheck to trap when > a problem is > > detected so a programmer can use the debugger to find the cause of the > > problem. > > That's pretty cool. > > What if we just built gdbstub into Valgrind, so you could use that > interface? Would that do the trick? Does that protocol do everything > necessary? It seems nice since it doesn't explicitly expose any > Valgrind-internal structures. I hadn't seen gdbstub but that seems like the right way to do this, probably using a TCP connection. > > While its easy to get and set the machine state for Valgrind threads, > there's no explicit mechanism for doing breakpoints, single stepping, > etc. Did you work around this, or just ignore it for now. I added in mechanisms for beakpoints and single stepping (GDB sets implicit breakpoints so doesn't work unless these are supported). Breakpoints end the basic block and return a certain value in %ebp which causes SIGTRAP to be raised. Single stepping just causes one instruction to be translated then similarly raises SIGTRAP. > > Also, when you use the debugger to change the machine state, you'd need > to come up with some plausible way to tell the tools about what they > need to know. Though thinking about it, the right calls into the tools > probably already exist. I haven't worried about what happens if the debugger modifies the process's memory so far. > > And it would be really nice to resurrect Nick's interactive inspection > tool, so we can add tool-specific extension which allow you to inspect > tool state. > > If you want to get this into CVS, the first obvious step is to port it > to the CVS version. We're planning on a number of largeish changes in > the next few months, so it's a bit unclear when the best time to merge > will be (maybe its now, given how quiet it has been for the last month > or so). But in the meantime, you should port your changes and track the > core. Some things to keep in mind while you port to the CVS version > are: > * we're thinking of moving the threading emulation down to the > kernel level, so we'll be using standard glibc pthread (either > nptl or LinuxThreads), but virtual cloned kernel tasks This shouldn't cause *too* many problems. > * we're likely to be porting to one or more non-x86 CPUs in the > medium term, so make sure you can clearly split out your > arch-specific parts Again, shouldn't be too much of a problem. > * we're also likely to be officially supporting other operating > systems (starting with Doug's FreeBSD port), so make sure that > any OS/library dependencies are factored out The code I've already written depends on Sys V IPC shm support but if gdbstub is used instead then this should be pretty OS neutral. > * now is also the right time to make the case for any VCPU, tool > interface or other core changes which would make this work > better/more easily This patch was supposed to form the basis of a larger project to add program tracing to GDB. I'm not sure if I have the time to move it to use gdbstub at present but I suspect it shouldn't be too hard if the breakpoint and single step support I've already implemented is reused. Regards, Chris |
|
From: Jeremy F. <je...@go...> - 2004-02-19 17:13:52
|
On Thu, 2004-02-19 at 03:38, Chris January wrote: > Hi all, > > I've been working on adding Valgrind support to GDB. I've written a GDB > target that allows you to debug a process running under Valgrind. The > threads emulated by vg_scheduler.c show up as normal threads and a special > thread 1 represents the real state of the process. For the implementation I > moved the VG_(threads) array to a shared memory region which can be accessed > by GDB to obtain the state of the emulated threads. I also added support for > single step and breakpoints to Valgrind. > The patches to Valgrind 2.0.0 and GDB 6.0 are available on my website > (www.atomice.com). > I was hoping that these patches could lead to an official method of exposing > the state of Valgrind's emulated threads to external debuggers. Inevitably > this would mean designing some kind of fixed structure containing a subset > of the thread state that wouldn't change from version to version. At present > the patches I've written are sensitive to changed in the ThreadState > structure. > I think it would also be useful once an external debugger interface is in > place to add an option to skins such as memcheck to trap when a problem is > detected so a programmer can use the debugger to find the cause of the > problem. That's pretty cool. What if we just built gdbstub into Valgrind, so you could use that interface? Would that do the trick? Does that protocol do everything necessary? It seems nice since it doesn't explicitly expose any Valgrind-internal structures. While its easy to get and set the machine state for Valgrind threads, there's no explicit mechanism for doing breakpoints, single stepping, etc. Did you work around this, or just ignore it for now. Also, when you use the debugger to change the machine state, you'd need to come up with some plausible way to tell the tools about what they need to know. Though thinking about it, the right calls into the tools probably already exist. And it would be really nice to resurrect Nick's interactive inspection tool, so we can add tool-specific extension which allow you to inspect tool state. If you want to get this into CVS, the first obvious step is to port it to the CVS version. We're planning on a number of largeish changes in the next few months, so it's a bit unclear when the best time to merge will be (maybe its now, given how quiet it has been for the last month or so). But in the meantime, you should port your changes and track the core. Some things to keep in mind while you port to the CVS version are: * we're thinking of moving the threading emulation down to the kernel level, so we'll be using standard glibc pthread (either nptl or LinuxThreads), but virtual cloned kernel tasks * we're likely to be porting to one or more non-x86 CPUs in the medium term, so make sure you can clearly split out your arch-specific parts * we're also likely to be officially supporting other operating systems (starting with Doug's FreeBSD port), so make sure that any OS/library dependencies are factored out * now is also the right time to make the case for any VCPU, tool interface or other core changes which would make this work better/more easily I assume that gdb is already pretty good at this portability stuff, so it won't be a huge issue. J |
|
From: Nicholas N. <nj...@ca...> - 2004-02-19 15:12:27
|
On Thu, 19 Feb 2004, Josef Weidendorfer wrote: > Is it OK to suggest to the Debian guys to downgrade to VG 2.0.x ? > (Of course, they optionally can include 2.1.x as separate package that is not > conflicting with the stable VG package). Seems reasonable to me. N |
|
From: Josef W. <Jos...@gm...> - 2004-02-19 15:05:58
|
Hi, as I have a bug report from a Calltree user for debian/unstable, which obviously only includes VG 2.1.0, I have a question... Was VG 2.1.x supposed to be released in distributions at all? Of course, we can't prohibit it, but should suggest a stable version to be distributed (i. e. 2.0.x, 2.2.x,...). My assumption was that VG 2.1.x is unstable and more or less kind of a better CVS-Snapshot. This is reflected by the Skin/Tool-API version number, which is *not* incremented in the 2.1.x series. So I never had in mind to support a 2.1.x release for Calltree, and that's because of the tool-API versioning policy not even possible in a sane way. But if VG 2.1.x is the only Valgrind version delivered with a distribution, you can't install Calltree, because there is no version for VG 2.1.x. Is it OK to suggest to the Debian guys to downgrade to VG 2.0.x ? (Of course, they optionally can include 2.1.x as separate package that is not conflicting with the stable VG package). Josef |
|
From: Chris J. <ch...@at...> - 2004-02-19 14:59:09
|
> On Thursday 19 February 2004 12:38, Chris January wrote: > > Hi all, > > > > I've been working on adding Valgrind support to GDB. I've written a GDB > > target that allows you to debug a process running under Valgrind. The > > Sounds quite cool. > What's a "GDB target" exactly? Is it a definition of a processor to be > debugged (e.g. register set...). The register set, etc. is a GDB architecture. A GDB target defines the mechanism for launching programs (e.g. setting LD_PRELOAD Valgrind), reading registers and memory, etc. > > > I was hoping that these patches could lead to an official method of > > exposing the state of Valgrind's emulated threads to external debuggers. > > The state of an emulated VG thread running e.g. with memcheck includes > the definedness of some memory cell. Can't this be seen as > additional state of > the new GDB target? I have no idea how to access this. Could it be a new > register (set) ? Someone else suggested using GDB's "call" feature to access skin-specific features such as this. This means a skin would have to deifne an external API that could be called by debuggers. > > > Inevitably this would mean designing some kind of fixed structure > > containing a subset of the thread state that wouldn't change > from version > > to version. At present the patches I've written are sensitive > to changed in > > If you could expose the additional state of VG tools as some "extented > processor registers", this would also mean some variable part > depending of > the actual tool used. Or a subtarget for every tool. A subtarget for every tool is probably the best option. I am already working on a subtarget for program traces. > > Josef > > > the ThreadState structure. > > I think it would also be useful once an external debugger > interface is in > > place to add an option to skins such as memcheck to trap when > a problem is > > detected so a programmer can use the debugger to find the cause of the > > problem. > > Comments and critcism welcome (and encouraged!) |
|
From: Chris J. <ch...@at...> - 2004-02-19 13:53:28
|
> On Thu, 19 Feb 2004, Chris January wrote: > > > --gdb-attach doesn't allow you to control execution from within > the debugger > > though does it? > > Correct. This sounds quite cool; I attempted something similar entirely > within Valgrind, by implementing a command-line from which you could set > breakpoints, run, etc (see www.cl.cam.ac.uk/~njn25/software.html under > "Interactive Mode"). Problem was that it didn't have all the built-in > infrastructure that gdb provides, particularly converting arbitrary > expressions (eg. foo->bar[5].baz) to addresses. > > One feature I've wanted for a while is a way to call tool-specified > functions from GDB, eg. with Memcheck call a function that tells you > whether a particular address is addressable, or if its value is defined. > I tried this with GDB a long time ago, just using the 'call' command, but > had problems with seg faults. Would this be possible with your patch? Not at present. The patch provides general support for Valgrind in GDB with no specific support for skins, etc. Using tghe call command to interrogate processes from GDB is an interesting concept. What would be great is to have a well-defined API that external debuggers could use (using something like the "call" mechanism) to interrogate a Valgrind process. Personally I developed this as the foundation for a larger effort to add support for program traces/program histories to GDB (using valgrind + a skin called logrind to collect them). What is the process for getting patches like this accepted into CVS? I appreciate that I may not have implemented things the way the developers may have preferred but I'd like to see some kind of external debugger support in Valgrind however it is implemented. In my experience it is easier to get developers of an open source project to consider a new feature if a patch is submitted, even if the patch is not used verbatim in the end. Regards, Chris |
|
From: Nicholas N. <nj...@ca...> - 2004-02-19 13:39:42
|
On Thu, 19 Feb 2004, Chris January wrote: > --gdb-attach doesn't allow you to control execution from within the debugger > though does it? Correct. This sounds quite cool; I attempted something similar entirely within Valgrind, by implementing a command-line from which you could set breakpoints, run, etc (see www.cl.cam.ac.uk/~njn25/software.html under "Interactive Mode"). Problem was that it didn't have all the built-in infrastructure that gdb provides, particularly converting arbitrary expressions (eg. foo->bar[5].baz) to addresses. One feature I've wanted for a while is a way to call tool-specified functions from GDB, eg. with Memcheck call a function that tells you whether a particular address is addressable, or if its value is defined. I tried this with GDB a long time ago, just using the 'call' command, but had problems with seg faults. Would this be possible with your patch? N |
|
From: Chris J. <ch...@at...> - 2004-02-19 12:46:10
|
> In message <ICE...@at...> > Chris January <ch...@at...> wrote: > > > I've been working on adding Valgrind support to GDB. I've written a GDB > > target that allows you to debug a process running under Valgrind. The > > threads emulated by vg_scheduler.c show up as normal threads > and a special > > thread 1 represents the real state of the process. For the > implementation I > > moved the VG_(threads) array to a shared memory region which > can be accessed > > by GDB to obtain the state of the emulated threads. I also > added support for > > single step and breakpoints to Valgrind. > > Er... You do know that we would quite like to drop valgrind's thread > emulation and switch to using the real system libpthread with real > cloned threads, don't you? > > I've no idea when it might happen, but it is something that has been > discussed several times because trying to maintain our own libpthread > is a lot of hard work, especially when it has to interoperate with > glibc properly. That's not a problem. What I really wanted to do was kickstart a discussion on the best way to expose the state of the emulated CPU to an external debugger. There's not really any difficulty in switching from libpthread emulation to real cloned threads. It just so happens that the current method of emulated threads was what was implemented when I was writing the patch . > > > The patches to Valgrind 2.0.0 and GDB 6.0 are available on my website > > (www.atomice.com). > > I would advise against doing any major work against 2.0.0 or you're > likely to have a hard time merging them with the current code. I realised this! That's why I wanted to discuss an 'official' way of exposing the state of the emulated CPU. > > > I think it would also be useful once an external debugger > interface is in > > place to add an option to skins such as memcheck to trap when > a problem is > > detected so a programmer can use the debugger to find the cause of the > > problem. > > Like --db-attach you mean? also known as --gdb-attach in current > release versions. --gdb-attach doesn't allow you to control execution from within the debugger though does it? My idea of trapping on a problem presupposed that external debugger support had been implemented. At present with the patches I wrote memcheck won't trap on a fault so you won't see where the problem occurred and --gdb-attach won't work because the process it already being debugged. Chris |
|
From: Tim T. <tj...@sa...> - 2004-02-19 12:45:42
|
Hi,
Don't know if you've had confirmation yet, but 2.1.0 runs ok for me
on RH9, at least for my application. If there are any other tests I can
do, let me know.
My machine:
- Dell c400 laptop
- RH9, kernel 2.4.20-30.9
- gcc3.2.2
- tim
--
================================================================
"You will keep in perfect peace him whose mind is
steadfast, because he trusts in you." Isaiah 26:3
Tim Tautges Sandia National Laboratories
(tj...@sa...) (telecommuting from UW-Madison)
phone: (608) 263-8485 1500 Engineering Dr.
fax: (608) 263-4499 Madison, WI 53706
|
|
From: Tom H. <th...@cy...> - 2004-02-19 12:19:42
|
In message <ICE...@at...>
Chris January <ch...@at...> wrote:
> I've been working on adding Valgrind support to GDB. I've written a GDB
> target that allows you to debug a process running under Valgrind. The
> threads emulated by vg_scheduler.c show up as normal threads and a special
> thread 1 represents the real state of the process. For the implementation I
> moved the VG_(threads) array to a shared memory region which can be accessed
> by GDB to obtain the state of the emulated threads. I also added support for
> single step and breakpoints to Valgrind.
Er... You do know that we would quite like to drop valgrind's thread
emulation and switch to using the real system libpthread with real
cloned threads, don't you?
I've no idea when it might happen, but it is something that has been
discussed several times because trying to maintain our own libpthread
is a lot of hard work, especially when it has to interoperate with
glibc properly.
> The patches to Valgrind 2.0.0 and GDB 6.0 are available on my website
> (www.atomice.com).
I would advise against doing any major work against 2.0.0 or you're
likely to have a hard time merging them with the current code.
> I think it would also be useful once an external debugger interface is in
> place to add an option to skins such as memcheck to trap when a problem is
> detected so a programmer can use the debugger to find the cause of the
> problem.
Like --db-attach you mean? also known as --gdb-attach in current
release versions.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Chris J. <ch...@at...> - 2004-02-19 11:42:44
|
Hi all, I've been working on adding Valgrind support to GDB. I've written a GDB target that allows you to debug a process running under Valgrind. The threads emulated by vg_scheduler.c show up as normal threads and a special thread 1 represents the real state of the process. For the implementation I moved the VG_(threads) array to a shared memory region which can be accessed by GDB to obtain the state of the emulated threads. I also added support for single step and breakpoints to Valgrind. The patches to Valgrind 2.0.0 and GDB 6.0 are available on my website (www.atomice.com). I was hoping that these patches could lead to an official method of exposing the state of Valgrind's emulated threads to external debuggers. Inevitably this would mean designing some kind of fixed structure containing a subset of the thread state that wouldn't change from version to version. At present the patches I've written are sensitive to changed in the ThreadState structure. I think it would also be useful once an external debugger interface is in place to add an option to skins such as memcheck to trap when a problem is detected so a programmer can use the debugger to find the cause of the problem. Comments and critcism welcome (and encouraged!) Chris -- http://www.atomice.com |
|
From: <js...@ac...> - 2004-02-19 04:11:26
|
Nightly build on phoenix ( SuSE 8.2 ) started at 2004-02-19 04:00:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow fi tls.c: In function `main': tls.c:92: warning: comparison between signed and unsigned if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -Winline -Wall -Wshadow -g -I../../include -MT tls2.o -MD -MP -MF ".deps/tls2.Tpo" \ -c -o tls2.o `test -f 'tls2.c' || echo './'`tls2.c; \ then mv ".deps/tls2.Tpo" ".deps/tls2.Po"; \ else rm -f ".deps/tls2.Tpo"; exit 1; \ fi gcc -Winline -Wall -Wshadow -g -I../../include -o tls -Wl,-rpath,. tls.o tls2.o tls.so -lpthread tls.so: undefined reference to `___tls_get_addr' collect2: ld returned 1 exit status make[4]: *** [tls] Error 1 make[4]: Leaving directory `/home/sewardj/ValgrindABT/valgrind/none/tests' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/home/sewardj/ValgrindABT/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/home/sewardj/ValgrindABT/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/sewardj/ValgrindABT/valgrind' make: *** [check] Error 2 |
|
From: <js...@ac...> - 2004-02-19 03:57:01
|
Nightly build on nemesis ( SuSE 9.0 ) started at 2004-02-19 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow then mv -f ".deps/tls.Tpo" ".deps/tls.Po"; \ else rm -f ".deps/tls.Tpo"; exit 1; \ fi if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -Winline -Wall -Wshadow -g -I../../include -MT tls2.o -MD -MP -MF ".deps/tls2.Tpo" \ -c -o tls2.o `test -f 'tls2.c' || echo './'`tls2.c; \ then mv -f ".deps/tls2.Tpo" ".deps/tls2.Po"; \ else rm -f ".deps/tls2.Tpo"; exit 1; \ fi gcc -Winline -Wall -Wshadow -g -I../../include -o tls -Wl,-rpath,. tls.o tls2.o tls.so -lpthread tls.so: undefined reference to `___tls_get_addr' collect2: ld returned 1 exit status make[4]: *** [tls] Error 1 make[4]: Leaving directory `/home/sewardj/ValgrindABT/valgrind/none/tests' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/home/sewardj/ValgrindABT/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/home/sewardj/ValgrindABT/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/sewardj/ValgrindABT/valgrind' make: *** [check] Error 2 |