Re: [Valgrind-developers] Valgrind support for GDB

[Jeremy F. <je...@go...>]

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