|
From: Paul P. <ppl...@go...> - 2009-08-13 17:22:31
|
On Thu, Aug 13, 2009 at 9:40 AM, Philippe Waroquiers<phi...@sk...> wrote: > When an error was encountered, this gdbserver was called; and was reporting > to gdb that a "break" was encountered. It was then possible to use gdb to > examine memory (print variables and similar). > A continue command in gdb was just causing gdbserver to return to valgrind > error mgr, which was then continuing to run as usual. AFAICT, the above in itself doesn't provide many benefits over the current scheme, except that GDB would not have to read symbolic debug info every time a new error is encountered (reading debug info can take minutes on large executables, so this benefit alone is not insignificant). A logical extension of this is to provide new GDB commands: is_mem_defined, is_mem_addressable, etc., and that (IMHO) would be a significant benefit, addressing real user needs (this is precisely what Nick Lewycky asked for). > The impact of this on valgrind looked relatively easy/low risk, and was more > or less working (after a limited dev. effort). I would definitely encourage you to finish this :-) The is_mem_* extension can then be done in cooperation with, or by GDB developers. > To the contrary, how the gdb could "interrupt" a running valgrind is > unclear. I think having breakpoints and is_mem* kills over 90% of actual use cases. While having 'Control-C' in GDB work would be nice, it's definitely not a "must have" requirement. Cheers, -- Paul Pluzhnikov |