Hello,
Since my original post, some progress has been done:
* the gdbserver code (about 6500 lines of wc *.c) has been changed to use
VG_() instead of libc
This was relatively mechanical (e.g. I did some simple emacs lisp to
replace various libc calls
by VG_ equivalent. If someone is interested, I can post it).
* a minimal "low target" for valgrind/X86 allows to read/write memory and
registers + continue execution
All that resulted in a "basic" working remote debugging of the valgrind client:
After the first error, valgrind waits for gdb to attach via the remote
protocol
gdb can then examine/modify the memory. The continue command continues the
execution
till the next error. valgrind then gives back the control to the gdb remote
stub.
(in other words, except that the memory of the client can be modified, it is
basically provides
the same features as the current --db-attach)
Many things are not done yet (e.g. threads not properly supported, no
breakpoint, no step, no watchpoint)
In parallel, I have received a private mail from someone telling me that his
company has developped
a gdb remote stub for valgrind (as part of another bigger work) and that this
should be contributed
soon to valgrind. This stub is more advanced than what I have done (e.g.
supports threads, more architectures),
and so I think I better continue to work based on this stub (when it is checked
in).
In summary, we have another new stub born :).
This gdb stub is however also not (yet) supporting
breakpoints/watchpoints/step, so that looks the
next thing to look at: it would be nice if gdb debugging a valgrind client
would support:
breakpoint/continue
step/continue
watchpoints (read, write, access)/continue
How to implement breakpoint is not clear to me, I put below some ideas.
Any feedback about this (or even better, give the really good idea about how to
do that) will be
very much appreciated
Approach "vex TRAP"
--------------------------------
Have a "vex TRAP " instruction doing no effect, except to stop the execution
and give back the control to the gdb remote stub.
With this, to put a break, the following then needs to be done:
* if the block in which the break has to be put is translated, then discard
the translation
* add the desired break address in a list of breaks
* in the JITter translater, when translating a block, insert the special
"vex TRAP" instruction
if the list of breaks contains an address inside the block being translated
Probably this would be reasonably efficient for normal breaks.
However, it is not clear how this would work for "single step": I assume that
it is not possible
to insert a TRAP instruction in a block being executed.
Approach "memory protection"
--------------------------------------------
Another approach might be to use some internal valgrind memory management
mechanism:
if in valgrind, it is possible to change the "protection" of a specific memory
location,
then it would be enough to make a memory location "not executable" (for a
break),
"not writeable" and/or "not readable" for a watchpoint.
I do not know if valgrind has such a fine-grain memory protection.
In this schema, a single step is also not clear to me.
Any hint/guidance will be welcome
Philippe
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Valgrind-developers mailing list
Valgrind-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
