|
From: Chris J. <ch...@at...> - 2005-01-09 14:40:56
|
> On Sat, 2005-01-08 at 20:20 +0000, Chris January wrote: > > > Yep, that would be nice to have. Do you have any more > > > concrete thoughts? It seems like a difficult problem,=20 > > > because there's nothing generic about a Tool; they can get=20 > > > very special purpose. How does one represent that on the=20 > > > wire, and how can a generic debugger deal with it once its there? > >=20 > > Tools would publish their own API helper libraries. These would=20 > > interpret the data stored in the tool specific area of the shared=20 > > memory region. A client could ask the API what information the tool=20 > > provided. A client would either request this information as=20 > a binary=20 > > structure, which it would then need to interpret, or could=20 > ask for it=20 > > in string form in which case it would be displayed=20 > unprocessed to the=20 > > user. > >=20 > > >=20 > > > > The only problem with the original shared memory implementation=20 > > > > was > > > > the exposure of internal data structures. To solve this=20 > problem I=20 > > > > propose adding a debugging API shared library to Valgrind. This=20 > > > > library would be released as part of the Valgrind package and=20 > > > > installed at the same time. The library could therefore=20 > freely use=20 > > > > access internal data structures without any problems.=20 > > > Valgrind's core > > > > would expose useful debugging information, such as=20 > registers, and > > > > debugging control variables such as single stepping=20 > through shared=20 > > > > memory as before (either SysV or mmap). > > >=20 > > > (I don't think shared memory would be a good idea. It would > > > preclude remote machine access, and adds a complex protocol=20 > > > overhead for synchronizing between the debugger and the=20 > > > Valgrind threads.) > >=20 > > It's not difficult to synchronise between the debugger and Valgrind=20 > > threads. That is to say, I encountered no problems=20 > implementing this. >=20 > Well, I've just rearranged the internals again which affects=20 > the thread structure. Sure, the basic debugging pattern will=20 > be "stop the world; inspect modify state; resume the world",=20 > so there isn't much concurrency, but I don't understand what=20 > advantage using shared memory offers. You can't inspect or modify the state of the inferior process easily if = it's running under Valgrind because the register sets are not stored in = kernel space, they are stored at an unknown location in the inferior process. Shared memory effectively gives you a known location to look for the register sets and other information.=20 > Also, now that Valgrind can self-virtualize, you need to be=20 > able to deal with multiple Valgrind instances within one=20 > process, and be able to distinguish them. I don't think this is really necessary and GDB doesn't support this kind = of architecture anyway. >=20 > > The advantage of the debugging API is you can implement the GDB=20 > > protocol atop of it (e.g. for remote debugging or to=20 > support debuggers=20 > > without a Valgrind target), but you are not limited to it. It also=20 > > means the GDB server can be a separate component, whereas=20 > without the=20 > > API it would be more closely coupled to the Valgrind core. >=20 > What about the other way around? Is the gdb protocol=20 > completely inextensible? It's inextensible in the sense that any extension would require changes = to GDB which is what we were trying to avoid in the first place. >=20 > I think the internal interface to any debugging protocol=20 > driver will be pretty simple anyway, so there's no particular=20 > advantage to deep layering. All it needs to be able to do is=20 > to be able to drive some async IO and inspect/modify memory=20 > and the ThreadState structures. Shared memory would make it=20 > more complex by adding more state to manage. Shared memory actually reduces the amount of state to manage because you don't have to worry about the inferior process at all - all interaction = is with the shared memory region. Chris |