|
From: Chris J. <ch...@at...> - 2005-01-10 09:18:34
|
> I think we're talking at cross purposes a bit. > I see it as a pretty serious limitation that you can't use gdb on a program while it runs under Valgrind. If > we implement the gdbstub protocol, we fix this in a very satisfactory way, since its immediately usable by > anyone who has pretty much any version of gdb installed. It's nice for us too, since the protocol is stable > and self-contained, and won't pose any maintenance headaches. It's the 95% solution. I agree a gdb stub is very useful. I proposed building it on top of the debugging API rather than directly accessing internal data structures for several reasons: i) it makes the gdb stub even less maintenance. If we design the API well enough to enable forward compatibility then we need never touch the gdb stub code again, even if major internal changes occur. ii) the gdb stub needs access to internal data structures one way or another, be it through an API or directly. If the stub runs in the same address space as the inferior it is prone to corruption by the inferior. Also the Linux clone syscall is non-portable and on other platforms the stub may also share other process characteristics such as files. This could cause problems if, e.g. the inferior tried to close one of the stub's file descriptors. This one of the reasons I proposed using shared memory - it isolates the debugger/stub from the inferior. iii) the gdb stub needs to be able to reliably stop the inferior. This could prove problematic if the stub was actually running in a thread as part of the inferior process. E.g. pending signals would be delivered to the stub thread. I am not suggesting using shared memory because it means we can get that extra 5%, as you put it. I am suggesting it because I believe it to be the simplest and most reliable solution. An API to access that shared memory is then just common sense - it doesn't have to be complicated in any way. Chris |