RE: [Valgrind-developers] Valgrind support for GDB

[Chris J. <ch...@at...>]

> 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