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.
ptrace as an API is really ugly but it works. GDB internally already has an
abstraction on top of it (linux-nat.c as a target).
We definitely need some serialized protocol as we need remote debugging with
multiple inferiors for cloud.
The gdb remote protocol is already very thin to just provide some
"ptrace-like" functionality serialized over the wire.
I already tried (test only, not indended for a production) once to "replace
ptrace" with disagreement on the design:
Re: Proof-of-concept on fd-connected linux-nat.c server
http://sourceware.org/ml/archer/2009-q2/msg00082.html
I do not see why to create a new layer (your `new generic API') between kernel
and gdbserver-in-userland.
> 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.
> 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.
Thanks,
Jan
