|
From: Jeremy F. <je...@go...> - 2005-01-10 18:08:21
|
On Mon, 2005-01-10 at 09:18 +0000, Chris January wrote: > 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. Well, maybe. gdbstub is so simple, I would be surprised if there were much difference in maintenance difficulty. > 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. Um, but it won't be. The inferior will be the client running under Valgrind, but gdbstub will be part of Valgrind itself. It as if the CPU has gdbstub built into it. > 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. ? I'm not sure what you're addressing here? Valgrind will only use clone() on Linux systems anyway. > 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 wouldn't implement the stub as a separate thread. I think it would be better implemented as an I/O+event-driven coroutine. I wouldn't want to add any extra threads (especially having just got rid of them all). J |