gdbstub initial code, another approach

[Frank Ch. Eigler]

Hi, Oleg -


> [...]
> But I do not see how in-kernel gdbstub can help even to prototype
> things. In my opinion it only complicates this. If nothing else,
> it is not easy to test even the simple things. Just imagine the
> simple tests like ptrace-tests rewritten to work via remote
> protocol.

(One could use a new user-space library.  There is not that much
complexity difference between a write/read syscall pair and a complex
ioctl.)


> IIUK, the main goal is prototype the new generic API [...]  It would
> be (I think) much easier to teach the real gdbserver and/or gdb to
> use this new API if we already had the userspace aplication which
> actually works using this API.

To an extent, it's all a SMOP.  But the key is the level of
abstraction provided by any new API.  ptrace(2) is low, the
gdb-wire-protocol is high, and both are pretty well established.  A
brand new API aiming into some new middle point will be harder to
validate.


> OTOH, with this split we still have the same advantage: we can
> use gdb to prove that this code can do something useful.

Not if you run into the exact same multithreading protocol glitches,
but this time with three separate interacting bodies of code instead
of two.


- FChE