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
(4) |
|
2
(5) |
3
(3) |
4
(3) |
5
(7) |
6
(7) |
7
(9) |
8
(10) |
|
9
(12) |
10
(26) |
11
(9) |
12
(6) |
13
(7) |
14
(15) |
15
(25) |
|
16
(20) |
17
(32) |
18
(11) |
19
(19) |
20
(22) |
21
(6) |
22
(8) |
|
23
(16) |
24
(25) |
25
(11) |
26
(16) |
27
(12) |
28
(15) |
29
(11) |
|
30
(5) |
31
(8) |
|
|
|
|
|
|
From: Jeremy F. <je...@go...> - 2005-01-10 23:10:50
|
On Mon, 2005-01-10 at 09:44 -0800, Naveen Kumar wrote:
> Hello all,
> I am having a problem with stage2 execution.
> Basically the program core dumps and I dont know how
> to figure out why and where. I know that uptil the
> point ume_go to start executing stage2 it is ok. After
> that the debugger is unable to get any symbols. How
> can I debug this ?
With difficulty. I spent a fair amount of time grovelling around in
assembler to get everything just right, and having the glibc source
definitely helped.
Some things to look at are:
* Try linking stage2 as static
* If you're using gdb, use "symbol-file stage2" to load stage2's
symtab
* compare the contents of the AUVX the kernel hands a new process
with what you're passing to stage 2
* look at all the addresses in the stage2 AUVX to make sure they
look sane
* also check argv and the environment
* look at the faulting instruction and see if the address its
faulting on look similar to any of the AUXV ones
J
|
|
From: Nicholas N. <nj...@ca...> - 2005-01-10 20:48:01
|
On Mon, 10 Jan 2005, Jeremy Fitzhardinge wrote: >> - First up, you have used AS_HELP_STRING in configure.in but >> none of my older systems know that even though they have >> newer autoconfs than they originally shipped with. Only a >> problem for people using CVS of course. > > That seems to be a general autoconf problem. I had to install a new > autoconf on my RH7.3 system to get the CVS HEAD to build anyway. I've seen that problem before too -- IIRC, I handled it by just writing the string directly instead of using AS_HELP_STRING; it may not be the "proper" way, but it works, and it's only an error msg in the autconf output that is slightly affected. N |
|
From: Jeremy F. <je...@go...> - 2005-01-10 18:08:21
|
On Mon, 2005-01-10 at 09:18 +0000, Chris January wrote: > i) it makes the gdb stub even less maintenance. If we design the API well > enough to enable forward compatibility then we need never touch the gdb stub > code again, even if major internal changes occur. Well, maybe. gdbstub is so simple, I would be surprised if there were much difference in maintenance difficulty. > ii) the gdb stub needs access to internal data structures one way or > another, be it through an API or directly. If the stub runs in the same > address space as the inferior it is prone to corruption by the inferior. Um, but it won't be. The inferior will be the client running under Valgrind, but gdbstub will be part of Valgrind itself. It as if the CPU has gdbstub built into it. > Also the Linux clone syscall is non-portable and on other platforms the stub > may also share other process characteristics such as files. This could cause > problems if, e.g. the inferior tried to close one of the stub's file > descriptors. This one of the reasons I proposed using shared memory - it > isolates the debugger/stub from the inferior. ? I'm not sure what you're addressing here? Valgrind will only use clone() on Linux systems anyway. > iii) the gdb stub needs to be able to reliably stop the inferior. This could > prove problematic if the stub was actually running in a thread as part of > the inferior process. E.g. pending signals would be delivered to the stub > thread. I wouldn't implement the stub as a separate thread. I think it would be better implemented as an I/O+event-driven coroutine. I wouldn't want to add any extra threads (especially having just got rid of them all). J |
|
From: Jeremy F. <je...@go...> - 2005-01-10 18:03:25
|
On Mon, 2005-01-10 at 16:53 +0000, Julian Seward wrote:
> > Oh, it definitely works. There are messages coming out, but it mostly
> > looks like ld.so suppressable chaff. And I fixed a leak after I did the
> > malloc/free substitution.
>
> Good.
>
> What leak is that? I would be interested to see it.
There were a handful of small leaks, but the biggest was this:
if(VG_(strncmp)(si->symtab[i].name, VG_INTERCEPT_PREFIX,
VG_INTERCEPT_PREFIX_LEN) == 0) {
int len = VG_(strlen)(si->symtab[i].name);
char *buf = VG_(malloc)(len), *colon;
intercept_demangle(si->symtab[i].name, buf, len);
colon = buf + VG_(strlen)(buf) - 1;
while(*colon != ':') colon--;
VG_(strncpy_safely)(si->symtab[i].name, colon+1, len);
}
in vg_symtab2.c:canonicaliseSymtab(). (The "while(*colon != ':')..."
loop looks a bit dubious to me as well, since it will fail to terminate
if there's no ':'.)
But bear in mind I haven't run anything very complex under V+V yet, so
it hasn't really been exercised at all.
J
|
|
From: Naveen K. <g_n...@ya...> - 2005-01-10 17:44:19
|
Hello all, I am having a problem with stage2 execution. Basically the program core dumps and I dont know how to figure out why and where. I know that uptil the point ume_go to start executing stage2 it is ok. After that the debugger is unable to get any symbols. How can I debug this ? Thanks Naveen __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Tom H. <th...@cy...> - 2005-01-10 17:00:47
|
In message <1105375498.29068.48.camel@localhost.localdomain>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Mon, 2005-01-10 at 10:17 +0000, Tom Hughes wrote:
>
>> The problem is that the LDT needs to be copied from the parent
>> thread when a child is created. That is done by VGA_(setup_child)
>> but that is no longer being called.
>>
>> If you change do_clone() and add this line just before the
>> code to handle SETTLS then it should work:
>>
>> VGA_(setup_child)(&ctst->arch, &ptst->arch);
>
> Oh, good. For completely correctness, shouldn't they be shared? If one
> thread later uses an LDT-changing call, should that be reflected in the
> other threads?
I'm not sure. I don't think that's my code - the TLS work is mine
but the LDT stuff for linuxthreads already existed.
My memory is that the kernel normally copies the LDT when creating
a new task but I might be wrong.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Julian S. <js...@ac...> - 2005-01-10 16:53:30
|
> Oh, it definitely works. There are messages coming out, but it mostly > looks like ld.so suppressable chaff. And I fixed a leak after I did the > malloc/free substitution. Good. What leak is that? I would be interested to see it. J |
|
From: Jeremy F. <je...@go...> - 2005-01-10 16:45:57
|
On Mon, 2005-01-10 at 10:17 +0000, Tom Hughes wrote: > In message <yek...@au...> > Tom Hughes <th...@cy...> wrote: > > > - RH72 and RH73 hang in corecheck/tests/pth_atfork1 > > > > - RH80 hangs in corecheck/tests/pth_cancel1 > > The RH80 hang is LDT related, and I suspect the other one is the > same but I haven't checked it. I assume this is the problem that > you were talking about Jeremy? > > The problem is that the LDT needs to be copied from the parent > thread when a child is created. That is done by VGA_(setup_child) > but that is no longer being called. > > If you change do_clone() and add this line just before the > code to handle SETTLS then it should work: > > VGA_(setup_child)(&ctst->arch, &ptst->arch); Oh, good. For completely correctness, shouldn't they be shared? If one thread later uses an LDT-changing call, should that be reflected in the other threads? J |
|
From: Jeremy F. <je...@go...> - 2005-01-10 16:44:18
|
On Mon, 2005-01-10 at 13:33 +0000, Nicholas Nethercote wrote: > Feels to me like the right way to do this is to get function wrapping > working somehow, ie. allowing Valgrind tools to augment functions like > pthread_mutex_lock() with some extra code (this is different to function > replacement, which we currently use extensively; we don't want to have > to duplicate the functionality of the original function). I can't > remember if this has been discussed previously (probably) and if so, what > the general opinion was about how easy/reliable it is. Well, to be really useful, we need to determine some internal state of the pthreads library. With pthread_mutex_lock, we want to know when its about to block trying to take a lock, as well as when it has actually taken the lock. The first one is tricky, and not easily derivable from plain wrapping (unless we run a parallel simulation of pthreads to model what each particular call is going to do, which sounds fragile). > I second Julian in saying that it would be nice to see a bit more > polishing before it goes in. Looking at the patch, there are a few parts > that say "XXX" or "must fix this later"... it would be good to fix these, > otherwise they're likely to stay that way for a while. I'll review them. > And the things Tom > has found, obviously. Yep. > Also, there's the question of how this will interact with Julian's private > VCPU changes. It could be a tricky merge. I made almost no changes to vg_to/from_ucode, so I'm assuming that there's not much interaction. J |
|
From: Jeremy F. <je...@go...> - 2005-01-10 16:39:49
|
On Mon, 2005-01-10 at 12:26 +0000, Nicholas Nethercote wrote: > > Nothing major. A few little bugfixes around the place (ironic that > > vg_to_ucode can't parse the code generated by vg_from_ucode). > > I would have thought the memory layout inflexibilities would have caused > problems. Where in the address space are the two Valgrinds going? It works out naturally. The first Valgrind grabs the top of the address space, and the next one takes the chunk below that; PIE means they can relocate themselves. The only change I had to make was to ignore /proc/self/maps entries above VG_(valgrind_last). > Can you try doing a meaningless jump on an uninitialised variable, or > something else that doesn't involve malloc? It would nice reassuring to > know that it really is working ok. Oh, it definitely works. There are messages coming out, but it mostly looks like ld.so suppressable chaff. And I fixed a leak after I did the malloc/free substitution. J |
|
From: Jeremy F. <je...@go...> - 2005-01-10 16:34:19
|
On Mon, 2005-01-10 at 09:45 +0000, Tom Hughes wrote: > Right. I've tried it on a range of systems now. Initial comments > are that it all looks pretty nice but I have a few problems... Download a new copy of the patch; I've fixed some things since the first announce. > - First up, you have used AS_HELP_STRING in configure.in but > none of my older systems know that even though they have > newer autoconfs than they originally shipped with. Only a > problem for people using CVS of course. That seems to be a general autoconf problem. I had to install a new autoconf on my RH7.3 system to get the CVS HEAD to build anyway. > - Second, on RH9 the clone used to start threads is not trapped > because CLONE_SYSVSEM is not set. I just added an extra case > for that to the switch. I changed the switch to only look at flags we really care about. > The big one is that something is causing it to hang. Different systems > hang in different places but all my systems hang at some point during > the regression tests: > > - RH72 and RH73 hang in corecheck/tests/pth_atfork1 > > - RH80 hangs in corecheck/tests/pth_cancel1 > > - RH9 and FC3 hang in none/tests/x86/yield The yield one is a bug in the test. It should be pthread_cond_broadcast, not signal. But the test is bogus now anyway, since it asserts that "rep;nop" has the same scheduling effect as "sched_yield", which definitely isn't true now. J |
|
From: Nicholas N. <nj...@ca...> - 2005-01-10 13:33:23
|
On Thu, 6 Jan 2005, Jeremy Fitzhardinge wrote: > All this has resulted in Valgrind shrinking by about 6600 lines of code, > including all of vg_proxylwp.c, vg_libpthread.c and about 2200 lines > from vg_scheduler.c - some of the hairest, trickiest and error-prone > code in the codebase. Woo! > There are some disadvantages though. In losing vg_libpthread, Valgrind > has a much more limited understanding of what's going on inside a > threaded program. It can see threads starting and exiting, but that's > ... > Probably the best way to fix this is to work with the glibc people to > try to build some Valgrind support into glibc, and/or take advantage of > the existing hooks which gdb uses. I haven't investigated this at all > yet. Relying on glibc doesn't sound so good to me -- it assumes the program uses glibc and not another way, and will also not be any good for existing versions of glibc. Feels to me like the right way to do this is to get function wrapping working somehow, ie. allowing Valgrind tools to augment functions like pthread_mutex_lock() with some extra code (this is different to function replacement, which we currently use extensively; we don't want to have to duplicate the functionality of the original function). I can't remember if this has been discussed previously (probably) and if so, what the general opinion was about how easy/reliable it is. > Other changes: I took advantage of the general upheaval to try to > isolate more of the OS/arch/platform dependent code. Sounds good. Hopefully it will hold up to a OS-porting effort. I second Julian in saying that it would be nice to see a bit more polishing before it goes in. Looking at the patch, there are a few parts that say "XXX" or "must fix this later"... it would be good to fix these, otherwise they're likely to stay that way for a while. And the things Tom has found, obviously. Also, there's the question of how this will interact with Julian's private VCPU changes. It could be a tricky merge. I think it's great you've got this working! So much nasty code removed, it's great :) I'd love to know how many of the open bugs will eventually be able to be closed by these changes... and self-hosting will be awesome too. Great stuff! N |
|
From: Nicholas N. <nj...@ca...> - 2005-01-10 12:26:24
|
On Sun, 9 Jan 2005, Jeremy Fitzhardinge wrote: >> That's really amazing. What changes beyond the threading one did you >> have to make? > > Nothing major. A few little bugfixes around the place (ironic that > vg_to_ucode can't parse the code generated by vg_from_ucode). I would have thought the memory layout inflexibilities would have caused problems. Where in the address space are the two Valgrinds going? >> So, can you complete the trick by making the inner V do allocation >> via malloc/free (or whatever) in such a way that the outer V can >> memcheck it and find real bugs therein? > > Yes, but I haven't done that much. I tried annotating vg_malloc2.c, but > got stuck trying to work it all out and figured that you or Nick would > be better people to do it. Can you try doing a meaningless jump on an uninitialised variable, or something else that doesn't involve malloc? It would nice reassuring to know that it really is working ok. N |
|
From: Tom H. <th...@cy...> - 2005-01-10 10:45:42
|
CVS commit by thughes:
Broadcast the condition variable instead of signalling because we
want to wake both the threads. Also initialise the mutex and condition
variable properly.
M +3 -3 yield.c 1.3
--- valgrind/none/tests/yield.c #1.2:1.3
@@ -4,6 +4,6 @@
#include <unistd.h>
-static pthread_mutex_t m_go;
-static pthread_cond_t c_go;
+static pthread_mutex_t m_go = PTHREAD_MUTEX_INITIALIZER;
+static pthread_cond_t c_go = PTHREAD_COND_INITIALIZER;
static volatile int alive;
@@ -56,5 +56,5 @@ int main()
pthread_mutex_lock(&m_go);
alive = 1;
- pthread_cond_signal(&c_go);
+ pthread_cond_broadcast(&c_go);
pthread_mutex_unlock(&m_go);
|
|
From: Tom H. <th...@cy...> - 2005-01-10 10:17:42
|
In message <yek...@au...>
Tom Hughes <th...@cy...> wrote:
> - RH72 and RH73 hang in corecheck/tests/pth_atfork1
>
> - RH80 hangs in corecheck/tests/pth_cancel1
The RH80 hang is LDT related, and I suspect the other one is the
same but I haven't checked it. I assume this is the problem that
you were talking about Jeremy?
The problem is that the LDT needs to be copied from the parent
thread when a child is created. That is done by VGA_(setup_child)
but that is no longer being called.
If you change do_clone() and add this line just before the
code to handle SETTLS then it should work:
VGA_(setup_child)(&ctst->arch, &ptst->arch);
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2005-01-10 09:59:35
|
In message <yek...@au...>
Tom Hughes <th...@cy...> wrote:
> - RH9 and FC3 hang in none/tests/x86/yield
This is a bug in the test - it does a signal on the CV when it
actually wants to wake both threads so should do a broadcast. It
seems that we used to wake both threads anyway ;-)
The test still fails because the yield thread yields many more
times that the one that spin waits.
I think the mutex and CV should also be initialised using the
proper static initialiser for the code to be truly correct.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2005-01-10 09:45:59
|
In message <1105074377.32288.52.camel@localhost>
Jeremy Fitzhardinge <je...@go...> wrote:
> So, the patch is at
> http://www.goop.org/~jeremy/valgrind/new-threading.patch.bz2
>
> If people could try it out and see if it basically works for them, I'll
> check it in the next few days. In particular, I'd like it if the people
> considering porting Valgrind to other OS's could have a look and see how
> these changes affect them.
Right. I've tried it on a range of systems now. Initial comments
are that it all looks pretty nice but I have a few problems...
- First up, you have used AS_HELP_STRING in configure.in but
none of my older systems know that even though they have
newer autoconfs than they originally shipped with. Only a
problem for people using CVS of course.
- Second, on RH9 the clone used to start threads is not trapped
because CLONE_SYSVSEM is not set. I just added an extra case
for that to the switch.
The big one is that something is causing it to hang. Different systems
hang in different places but all my systems hang at some point during
the regression tests:
- RH72 and RH73 hang in corecheck/tests/pth_atfork1
- RH80 hangs in corecheck/tests/pth_cancel1
- RH9 and FC3 hang in none/tests/x86/yield
I haven't tried to work out what is causing any of the hangs yet.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Chris J. <ch...@at...> - 2005-01-10 09:18:34
|
> I think we're talking at cross purposes a bit. > I see it as a pretty serious limitation that you can't use gdb on a program while it runs under Valgrind. If > we implement the gdbstub protocol, we fix this in a very satisfactory way, since its immediately usable by > anyone who has pretty much any version of gdb installed. It's nice for us too, since the protocol is stable > and self-contained, and won't pose any maintenance headaches. It's the 95% solution. I agree a gdb stub is very useful. I proposed building it on top of the debugging API rather than directly accessing internal data structures for several reasons: i) it makes the gdb stub even less maintenance. If we design the API well enough to enable forward compatibility then we need never touch the gdb stub code again, even if major internal changes occur. ii) the gdb stub needs access to internal data structures one way or another, be it through an API or directly. If the stub runs in the same address space as the inferior it is prone to corruption by the inferior. Also the Linux clone syscall is non-portable and on other platforms the stub may also share other process characteristics such as files. This could cause problems if, e.g. the inferior tried to close one of the stub's file descriptors. This one of the reasons I proposed using shared memory - it isolates the debugger/stub from the inferior. iii) the gdb stub needs to be able to reliably stop the inferior. This could prove problematic if the stub was actually running in a thread as part of the inferior process. E.g. pending signals would be delivered to the stub thread. I am not suggesting using shared memory because it means we can get that extra 5%, as you put it. I am suggesting it because I believe it to be the simplest and most reliable solution. An API to access that shared memory is then just common sense - it doesn't have to be complicated in any way. Chris |
|
From: <js...@ac...> - 2005-01-10 03:56:34
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-01-10 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 188 tests, 5 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) memcheck/tests/scalar (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2005-01-10 03:24:16
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-01-10 03:20:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int sh: line 1: 8923 Illegal instruction VALGRINDLIB=/tmp/valgrind.25270/valgrind/.in_place /tmp/valgrind.25270/valgrind/./coregrind/valgrind --tool=none ./int >int.stdout.out 2>int.stderr.out rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-10 03:20:08
|
Nightly build on audi ( Red Hat 9 ) started at 2005-01-10 03:15:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 12 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-10 03:13:53
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-01-10 03:10:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/scalar (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-10 03:08:35
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-01-10 03:05:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/susphello (stdout) none/tests/susphello (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-10 03:03:58
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-01-10 03:00:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/susphello (stdout) none/tests/susphello (stderr) make: *** [regtest] Error 1 |
|
From: Jeremy F. <je...@go...> - 2005-01-10 00:15:34
|
I think we're talking at cross purposes a bit.
I see it as a pretty serious limitation that you can't use gdb on a
program while it runs under Valgrind. If we implement the gdbstub
protocol, we fix this in a very satisfactory way, since its immediately
usable by anyone who has pretty much any version of gdb installed. It's
nice for us too, since the protocol is stable and self-contained, and
won't pose any maintenance headaches. It's the 95% solution.
Sure, it would be nice to get the other 5%, some way of querying Tool
state from within the debugger. That could be solved either by
proposing a new debugger interface, or by trying to squeeze more out of
the gdbstub interface (by, for example, finding some way to set
breakpoints/watchpoints which are triggered by a Tool warning message).
I think the first is really important. We can worry about the second
once the first is in place. Holding back the first 95% of the answer
just so we can get the last 5% doesn't seem like a good tradeoff.
J
|