Re: gdbstub initial code, another approach

[Oleg Nesterov <oleg@redhat.com>]

On 07/30, Jan Kratochvil wrote:
>
> On Fri, 30 Jul 2010 16:41:24 +0200, Oleg Nesterov wrote:
> > 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 ?
>
> So far I just assumed kernel-space ugdb is the plan.  As I wrote before I do
> not know gdbserver too much.

I am not sure, but I do not really know.

Jan, all, let me explain again what I think.

Yes, as I said I personally do not believe in in-kernel gdbstub too much.
If nothing else, I bet it will be never merged upstream. Unless at least
this code will also have the more "traditional" user-space API which is
immediately clear to the reviewers on lkml.

And how we can implement, say, vRun in kernel? I am not saying this is
technically impossible, but this against the common sense, imho.

Or remote debugging via tcp. We need the user-space helper anyway. Again,
of course it is technically possible to create the socket and the kernel
thread which serves the requests, but I don't think we should do this.

Or two modes, all-stop and non-stop. Imho, the kernel shouldn't even
know about this. Or register renumbering.


However. I have also said that my opinion doesn't matter. And I meant
this! I do not understand the user-space needs, I do not understand the
problems from the gdb's pov. So, we can put this code in kernel later,
in the same module or another one if this is really needed.

At least the prototyping is much easier in user-space. And I hope very
much this helps to separate the utrace problems and the protocol problems.

I may be wrong, but the most complex "conceptual" part is the thread
management. I mean the very basic things: attach, detach, exit, clone.
But, from the remore protocol pov these things do not exist, gdbserver
hides this details. This is good for gdb, but complicates the testing
and surely this is not enough in general. Just think about /bin/strace.

Or. Currently I am not sure gdbstub does exactly same as the real
gdbserver when the main thread exits. But I do not care at all, it would
be trivial to change this user-level code if needed without changing
the implementation details in kernel.

> Catching up with systemtap's 200x higher software-watchpoint performance over
> current (local) gdb (described in "[debug-list] Utrace Discussion Notes" off
> this list) could be easier with in-kernel gdb I thought.

Perhaps, I can't comment because I do not understand the problem space.

Oleg.