|
From: Chris J. <ch...@at...> - 2005-01-08 16:56:17
|
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 |