|
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: 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 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: 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 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: 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: 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: 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-20 07:54:11
|
> > > * 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. Plain old MAP_SHARED isn't supported on Linux so that would mean using POSIX shm (shm_open, /dev/shm) instead. I'm not sure how portable that is. Chris |
|
From: Tom H. <th...@cy...> - 2004-02-20 08:19:44
|
In message <ICE...@at...>
Chris January <ch...@at...> wrote:
> Plain old MAP_SHARED isn't supported on Linux so that would mean using POSIX
> shm (shm_open, /dev/shm) instead. I'm not sure how portable that is.
What do you mean by "plain old" exactly? I wasn't aware of any problem
with MAP_SHARED on linux.
I didn't even realise there was a POSIX shared memory interface, but
it does look like it fixes the worst of the Sys V shared memory
problems, the greatest of which is a tendency to leak the shared
memory if the owning process dies unexpectedly.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Chris J. <ch...@at...> - 2004-02-20 11:27:55
|
> In message <ICE...@at...> > Chris January <ch...@at...> wrote: > > > Plain old MAP_SHARED isn't supported on Linux so that would > mean using POSIX > > shm (shm_open, /dev/shm) instead. I'm not sure how portable that is. > > What do you mean by "plain old" exactly? I wasn't aware of any problem > with MAP_SHARED on linux. I just wrote a small test program and it appears MAP_SHARED does work. I don't know where I got the idea it didn't from! However it is probably best to avoid the use of shared memory altogether (since it means GDB needs to know about Valgrind's internal structures) and use something like gdbstub instead as someone else suggested. Chris |
|
From: Johan R. <jry...@ni...> - 2004-02-20 01:51:59
|
Jeremy Fitzhardinge <je...@go...> wrote: : 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 suggest you take a look at RDA, available from sources.redhat.com (look in the binutils CVS repo.) It gives you a full GDB stub by simply implementing a few callbacks. It is GPL'ed if I remember correctly. -- Johan Rydberg, Free Software Developer, Sweden http://rtmk.sf.net | http://www.nongnu.org/guss/ Playing air - mike mills |