Hello,
When an error is detected by valgrind, --db-attach allows the user to look at
the client being run.
As far as I understand, the started gdb can only be used to look at the client
memory. I think
this has a.o. the following limitations:
* the usual gdb commands (break, continue, next, step) cannot be used
* changing the client memory has no effect (I understood by quickly reading
the code of m_debugger.c that gdb is started on a forked copy, but not on
the "real" client)
These limitations are somewhat annoying.
E.g. when a program does not work under valgrind, be able to really debug the
client would be useful.
Also, some other features e.g. add breakpoints and (when break encountered) be
able to call some
valgrind services on the fly (such as search leaks, verify memory definedness,
...) would be nice.
I wonder if the idea that follows would not allow to obtain a "reasonably
debuggable" valgrind client,
at a reasonable implementation cost.
The idea is to implement in the valgrind core the "target" side of the gdb
remote debugging protocol
This remote debugging protocol (documented in the gdb user manual) has a simple
basis:
the mandatory subset of the "packets (i.e. commands)" is:
get/set registers
read/write <length> bytes at <address>
c/s (continue/step)
The protocol defines a lot of other optional commands, the one that looks
interesting to start with
to allow a "reasonably debuggable" client are:
set/clear breakpoints;
execute at the remote monitor <free command>
(there are many others, such as tracepoints/info about threads, etc) For a
complete info,
look in the gdb user manual in the annex describing the protocol.
gdb can send these packets either on a serial line or over tcp. To hook in
valgrind,
tcp should be used (I do not see how to connect a serial line to valgrind :).
If valgrind core supports this protocol, then it looks to me that we would
obtain
a "normally" debuggable client program.
An option --gdb-server=<host:portnr> would indicate to valgrind that it has to
listen
on this port nr for a gdb to connect. (the listen could be done before starting
up, or
if -db-attach is given, only when an error is encountered)
With the above 8 commands implemented + have a few free commands
such as "search_for_leaks", debugging a program "under valgrind" with the normal
gdb features would become feasible.
The protocol itself looks easy to implement (and there is code available in gdb
to start from)
but it is not clear to me if hooking this at valgrind side would be easy.
Here are a few unclear points/issues:
* I guess that reading (and sending back) the client registers is
straightforward
but what are the implications of setting the client registers ?
* Probably read/write the client memory has less implications:
reading should be straightforward
writing memory would only imply to change the shadow bits
* implement various "monitor" commands (such as search for leaks) would I
guess also
be relatively easy
* it is unclear to me how to implement a break. Maybe a new VEX IR "break"
instruction would be needed ?
Then when the set breakpoint packet is received, the translation for the
address of the break would have
to be discarded, and replaced by this special instruction. Then when this
VEX IR break instruction is
encountered, the gdbserver code would be executed. A continue would then
just continue the execution
* how to implement "step" is also not clear.
* implementing the "continue at address": is the valgrind core supporting to
"force a jump to a specific address" ?
* it would be nice to be able to "interrupt" the running valgrind program
when gdb sends a control-c
character on the remote connection to interrupt.
Probably this can be implemented by having the valgrind core "polling or
reading" from time to
time on the socket connection.
* any other thing to look at ? or any difficulty overlooked ?
Any feedback about the idea (e.g. interesting as a new valgrind feature ?
feasibility ? difficulty ? ...) welcome.
(sorry if my poor knowledge of valgrind implementation resulted in a naive and
unfeasible suggestion)
(if the feedback indicates that it is relatively easy, I might even be tempted
to implement
it during the free time which is left after my wife, my children and my work
have taken their
parts :)
Philippe Waroquiers
-------------------------------------------------------------------------
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
