This is the mail archive of the
mailing list for the Archer project.
Re: gdbstub initial code, another approach
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.
> 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.
> 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