|
From: Jeremy F. <je...@go...> - 2005-01-09 00:15:27
|
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, > > because there's nothing generic about a Tool; they can get > > very special purpose. How does one represent that on the > > wire, and how can a generic debugger deal with it once its there? > > Tools would publish their own API helper libraries. These would interpret > the data stored in the tool specific area of the shared memory region. A > client could ask the API what information the tool provided. A client would > either request this information as a binary structure, which it would then > need to interpret, or could ask for it in string form in which case it would > be displayed unprocessed to the user. > > > > > > 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). > > > > (I don't think shared memory would be a good idea. It would > > preclude remote machine access, and adds a complex protocol > > overhead for synchronizing between the debugger and the > > Valgrind threads.) > > It's not difficult to synchronise between the debugger and Valgrind threads. > That is to say, I encountered no problems implementing this. Well, I've just rearranged the internals again which affects the thread structure. Sure, the basic debugging pattern will be "stop the world; inspect modify state; resume the world", so there isn't much concurrency, but I don't understand what advantage using shared memory offers. Also, now that Valgrind can self-virtualize, you need to be able to deal with multiple Valgrind instances within one process, and be able to distinguish them. > The advantage of the debugging API is you can implement the GDB protocol > atop of it (e.g. for remote debugging or to support debuggers without a > Valgrind target), but you are not limited to it. It also means the GDB > server can be a separate component, whereas without the API it would be more > closely coupled to the Valgrind core. What about the other way around? Is the gdb protocol completely inextensible? I think the internal interface to any debugging protocol driver will be pretty simple anyway, so there's no particular advantage to deep layering. All it needs to be able to do is to be able to drive some async IO and inspect/modify memory and the ThreadState structures. Shared memory would make it more complex by adding more state to manage. J |