[Valgrind-developers] Debugging API proposal

[Chris J. <ch...@at...>]

In which I propose adding a shared library that implements an API for
accessing internal Valgrind data structures and tool-specific =
information.

Some time ago I submitted a patch to implement breakpoints and single
stepping in Valgrind. Hopefully that patch can be revisited and =
committed at
some stage because I have a proposal that builds on that patch to make.
As some of you may know I wrote some patches for Valgrind and GDB that
allowed GDB to debug processes running under Valgrind. I moved the
VG_(threads) structure to a shared memory region so that GDB could read =
the
register set of the threads from the structure. I also added a control
variable to enable single stepping. Now although this method worked fine =
it
was fragile because GDB needed to have intimate knowledge of the
VG_(threads) structure. I later proposed an alternative solution in =
which
Valgrind provided a GDB server that GDB could connect to. This seemed =
like
the 'right' solution at the time because GDB didn't need to have special
knowledge about Valgrind (or so I thought) and I began implementing it =
but
didn't have enough time to finish. However now I am revisiting the =
problem
and have concluded that this idea is not the best solution because:
a) it is limited to debuggers implenting the GDB remote debugging =
protocol.
b) it still needs a specialised Valgrind target for GDB to launch =
Valgrind
and connect to the server port in one operation. (I suppose it would be
feasible to have the user manually launch Valgrind and then have =
Valgrind
wait for GDB to connect but this is less than ideal.)
c) poor support for getting data from Valgrind's tools (e.g. memcheck). =
The
GDB protocol was never really designed for this.
The only problem with the original shared memory implementation was the
exposure of internal data structures. To solve this problem I propose =
adding
a debugging API shared library to Valgrind. This library would be =
released
as part of the Valgrind package and installed at the same time. The =
library
could therefore freely use access internal data structures without any
problems. Valgrind's core would expose useful debugging information, =
such as
registers, and debugging control variables such as single stepping =
through
shared memory as before (either SysV or mmap). The debugging API would =
know
the structure of this shared memory and access it on behalf of user
processes (such as a debugger). We could also add an API to Valgrind for
skins to publish similar skin-specific information.  The debugging API =
would
be lightweight and need not necessarily require many changes to =
Valgrind.

Comments and criticism welcome.

Chris

--
http://www.atomice.com