Re: gdbstub initial code, another approach

[Oleg Nesterov <oleg at redhat dot com>]

On 07/30, Jan Kratochvil wrote:
>
> On Fri, 30 Jul 2010 14:57:55 +0200, Oleg Nesterov wrote:
> > IIUK, the main goal is prototype the new generic API,
>
> As I thought there is an agreement the ptrace API has to stay.

Of course, ptrace can't go away.

> We definitely need some serialized protocol as we need remote debugging with
> multiple inferiors for cloud.

Nobody argues.

> I do not see why to create a new layer (your `new generic API') between kernel
> and gdbserver-in-userland.

Because gdb is not alone? I agree, it is probably most important.

> > 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.
>
> If it is only a development tool for the in-kernel server then OK.

Right now I do not know.

> > It would be (I think) much easier to teach the real
> > gdbserver and/or gdb to use this new API
>
> gdb linux-nat.c (=local gdb) should be deprecated.  There is definitely a need
> for remote target and actively maintaining two modes is not effective, we can
> run gdbserver even during single-host debugging.

OK,

> We can port gdbserver to anything but I do not see the point.  We should
> probably move the threading support from gdbserver to gdb but there isn't much
> left to do in userland gdbserver with properly designed kernel API.

IOW, you think that it is better to shift gdbserver into kernel-space
than port the existing one to the new API or write the new one in user
space ?

Oleg.