|
From: Chris J. <ch...@at...> - 2004-02-19 14:59:09
|
> 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!) |
|
From: Chris J. <ch...@at...> - 2004-02-20 11:39:39
|
> "Chris January" <ch...@at...> wrote: > > : 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 exactly do you mean by program traces/program histories? Collect > a full program path trace, like described in Larus' paper (Whole Program > Paths.) No, not quite as described in that paper. I'm thinking more of H. Agrawal, R. Demillo, and E. Spafford, "Debugging with Dynamic Slicing and Backtracking," Software-Practice and Experience, Vol.23, No.6, pp.589-616, 1993, i.e. collecting all reads/writes to registers/memory, function calls/returns, jumps, etc. (obviously with options to control exactly what is collected - you only actually need to record writes and jumps to reconstruct a program's execution) and using the information for dynamic slicing and similar things. Chris |
|
From: Nicholas N. <nj...@ca...> - 2004-02-20 12:53:02
|
On Fri, 20 Feb 2004, Chris January wrote: > > What exactly do you mean by program traces/program histories? Collect > > a full program path trace, like described in Larus' paper (Whole Program > > Paths.) > > No, not quite as described in that paper. I'm thinking more of H. Agrawal, > R. Demillo, and E. Spafford, "Debugging with Dynamic Slicing and > Backtracking," Software-Practice and Experience, Vol.23, No.6, pp.589-616, > 1993, i.e. collecting all reads/writes to registers/memory, function > calls/returns, jumps, etc. (obviously with options to control exactly what > is collected - you only actually need to record writes and jumps to > reconstruct a program's execution) and using the information for dynamic > slicing and similar things. You might be interested in a paper I wrote called "Redux: A dynamic dataflow tracer" (see www.cl.cam.ac.uk/~njn25/pubs.html). It describes a Valgrind tool I wrote that's quite similar to what's described in the Agrawal et al paper. N |