gdbstub initial code

[Roland McGrath]

> Given these requirements, and given that the 'new' uprobes is close to
> -tip, would it be more useful to pursue an alternate syscall approach
> rather than gdbstub?

Feel free to pursue whatever you like.  For our own time allocation, we
see an effort along those lines now as a distraction from work that will
really make a qualitative difference in the debugging experience.  Any
new interface is an instant source of endless discussions (at best)
about many details that are ultimately trivial in the greater scheme of
things.  Aside from flaming its details a priori, no new interface is of
any interest to anyone unless its use is integrated into real, non-toy
userland debugging tools and it enables their delivery of qualitatively
significant, new or better aspects of the debugging experience.  

Starting with a whole new interface inevitably involves spending most of
the time on the combination of LKML flames about the interface trivia
and work on toy userland libraries and utilities to demonstrate using
the new kernel features.  That's a whole lot more time and effort and
friction to come around to doing the toy version of what real userland
debugging tools do today, and maybe then start on doing anything that's
actually new or different beyond cleaning up pet-peeve interface trivia,
if you don't get too side-tracked filling in practical holes in your toy
tools along the way first.

What Oleg is embarking on now is a prototyping exercise.  We're not
trying to find a new kind of backwards to bend over to have upstream
people like any new interface layers.  We're trying to get quickly to
the experimental baseline from which we can try to come up with some of
those qualitatively significant new things.  That means having a full,
adult-sized, real-world debugging tool plugged into new and unencumbered
kernel code paths and doing approximately its normal thing at least as
well (approximately) as normal.  In the end, more of the work is on the
userland side (or in fritter about what the user-kernel interface
details should be) than the actual guts of the kernel-side work.  We've
chosen the gdb remote protocol as a prototype vehicle because we start
with about 95% complete support in our closest-to-hand real-world tool
(gdb) for that baseline.  (We also happen to have some gdb-hacking
colleagues nearby to help us experiment with anything that might rely on
that remaining 5% or otherwise on teaching gdb new tricks.)  Hence we
hope to get very quickly to that baseline for experimentation.

>From there we can start trying out the things that could really make a
big difference in what a debugger tool can do (or how well/fast it can
do them).  What matters for that isn't the little details of encodings
or syscall interfaces, but the large-granularity issues about how the
interface is used, like how many context switches back and forth to the
debugger it takes to get a task done, etc.  IMHO it would be pointless
to try to design any new interface before knowing concretely what kinds
of things on the big-idea scale make an important difference to the
actual debugging experience with a real-world tool like gdb.  When we've
shown what key features and characteristics deliver a big tangible
payoff, we can worry about how to formulate new interfaces or extensions
that both achieve those essential goods and meet with upstream tastes.


Thanks,
Roland