|
From: Philippe W. <phi...@sk...> - 2008-02-09 09:24:32
|
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
|
|
From: Bart V. A. <bar...@gm...> - 2008-02-09 12:05:19
|
On Feb 9, 2008 10:24 AM, Philippe Waroquiers <phi...@sk...> wrote: > The idea is to implement in the valgrind core the "target" side of the gdb > remote debugging protocol If you do this it is probably wise to try to find solid documentation of the gdb remote debugging protocol. I have used gdb remote debugging extensively while developing software for embedded devices, and I remember that at that time there were quite some bugs in the protocol implementation (both client side and server side). Bart. |
|
From: Philippe W. <phi...@sk...> - 2008-02-09 18:25:56
|
From: "Bart Van Assche" <bar...@gm...> Sent: Saturday, February 09, 2008 1:03 PM > <phi...@sk...> wrote: >> The idea is to implement in the valgrind core the "target" side of the >> gdb >> remote debugging protocol > > If you do this it is probably wise to try to find solid documentation > of the gdb remote debugging protocol. I have used gdb remote debugging > extensively while developing software for embedded devices, and I > remember that at that time there were quite some bugs in the protocol > implementation (both client side and server side). For the moment, the unknown factors for me are more related to valgrind core (cfr questions in the original mail). The gdb documentation looks reasonably clear at first sight, but of course it does not mean that it is correct and/or that the implementation of the protocol is correct. At what time did you work with this remote protocol ? Thanks Philippe |
|
From: Bart V. A. <bar...@gm...> - 2008-02-10 06:57:25
|
On Feb 9, 2008 7:25 PM, Philippe Waroquiers <phi...@sk...> wrote: > The gdb documentation looks reasonably clear at first sight, but of course > it does not mean that it is correct and/or that the implementation of the protocol > is correct. At what time did you work with this remote protocol ? It was about two years ago that I last reported a bug that was related to the gdb - gdbserver communication protocol. A quick look in the gdb bugzilla shows that there still may be issues with the remote debugging protocol implementation: http://sourceware.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=2301&return_url=http%3A%2F%2Fsourceware.org%2Fcgi-bin%2Fgnatsweb.pl%3Fdatabase%3Dgdb%26category%3Dall%26severity%3Dall%26priority%3Dall%26responsible%3Dall%26submitter_id%3Dall%26state%3Dall%26ignoreclosed%3DIgnore%2520Closed%26class%3Dall%26synopsis%3D%26multitext%3Dgdbserver%26columns%3Dcategory%26columns%3Dstate%26columns%3Dclass%26columns%3Dresponsible%26columns%3Dsynopsis%26displaydate%3DDisplay%2520Current%2520Date%26cmd%3Dsubmit%2520query%26sortby%3DResponsible%26.cgifields%3Ddisplaydate%26.cgifields%3Dignoreclosed%26.cgifields%3Doriginatedbyme%26.cgifields%3Dcolumns There also exists an enhanced version of gdbserver, called rproxy. Unfortunately the homepage of this project is no longer accessible (http://world.std.com/~qqi/labslave/rproxy.html). Bart Van Assche. |