Re: gdbstub initial code, another approach

[Oleg Nesterov <oleg@redhat.com>]

On 07/30, Frank Ch. Eigler wrote:
>
> 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.)

Oh. I do not think so. First af all, I do not know what this library
can actually do, except it can provide the helpers for get/put
packet plus some parsing. But in any case, we don't have this lib
right now.

And write/read pair is not only inconvenient. Imho, it is really
bad because read() is used for the asynchronous events as well.

> > 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.

Yes, agreed. But I hope that the user-space gdbserver which actually
works on top of this API can be considered as validation. IOW, if
this API is simple and good enough to write the reasonable gdbserver,
then it probably makes sense.

> > 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.

I don't understand this part. We already have some problems here,
with the existing protocol, yes. If we want to fix them, I do not
understand how the fact that some code runs in user-space can't
complicate things.

Oleg.