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