RE: [Valgrind-developers] Valgrind support for GDB

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

> 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!)