|
From: Philippe W. <phi...@sk...> - 2009-08-13 17:50:03
|
> 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). Effectively, once the basic gdb/gdb stub is working, that is the logical followup These commands are better done without changing gdb: gdb can send commands to the gdb stub without a need to understand them. E.g. memcheck commands would look like (gdb) monitor is_mem_defined 0xbeefdead 0xdeadbeef (gdb) monitor make_mem_undefined 0xdeadbeef (and similar for all the "interesting" client request) This has the advantage that there is no need to modify gdb (I suspect gdb people do not like too much the idea to integrate "valgrind only commands" in gdb). Note that a proper way to "interrupt" valgrind would be nice not only for gdb stub, but for any kind of external control of valgrind (similar to callgrind_control). Eg, if valgrind is able to "listen" for an external command when running or being in a blocking system call, then a variety of "tool commands" could be made available from command line even outside gdb such as: valgrind_control memcheck_do_leakcheck valgrind_control dump_massif_heap valgrind_control dump_callgrind_counters (the gdb stub code would be usable both by the command line interface and the gdb/gdb stub combination). I guess the above (and the control-c in gdb) can be implemented by polling. Only the "blocked in system call" would not work. Philippe |