Re: gdbstub initial code, another approach

[Oleg Nesterov <oleg@redhat.com>]

On 07/29, Frank Ch. Eigler wrote:
>
> Oleg Nesterov <oleg@redhat.com> writes:
>
> > [...]
> > 	- ugdb.c
> >
> > 		The kernel module which implements the basic
> > 		user-space API on top of utrace. Of course,
> > 		this API should be discussed.
> > 	- gdbstub
> >
> > 		The simple user-space gdbserver written in
> > 		perl which works with ugdb API.
> > [...]
>
> To the extent that the problems with an in-kernel gdbstub are
> weaknesses in the protocol - or gdb's implementation thereof - how
> would this split improve that situation?

I have the strong desire to ask you by turn why do you think
that in-kernel gdbstub can help in any way ;)

Yes, I never liked the idea of in-kernel gdbstub. Apart from
too-highlevel and vague it is also a bit limited. And some things,
say, register renumbering, doesn't belong to kernel. Or vRun.
Many other things. The only advantage is that we already have
the great tool which works with this protocol - gdb.

Ok, it is easy to criticize, and my opinion doesn't really matter.
We can put it in kernel later, when we have something more than
just the proof of concept.

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.

IIUK, the main goal is prototype the new generic API, while the
remote protocol (in my opinion) is obviously can't be considered
as such. With this split it is possible to try to add some API
and test it with or without gdb. Also, it is much more easy to
play with the the protocol extensions (which I believe it needs)
this way. 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.

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

Oleg.