lkml.org 
[lkml]   [2009]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.
    Hi -


    > > Help me out here: by "kgdb extension" do you imagine "something new
    > > that an unprivileged user can use to debug his own process"? Or do
    > > you imagine a new userspace facility that single-steps the kernel?
    >
    > Is this a trick question? Single-stepping the kernel on the same system
    > [especially if it's an UP system] would certainly be a challenge ;-)
    >
    > What i mean is what i said: if you provide a new framework (especially
    > if it's user visible - which both kgdb and the gdb stub is) you should
    > either fully replace existing functionality or extend it. Overlapping it
    > in an incomplete way is not useful to anyone.

    But there is no "overlap" beyond the name. The functional scope of
    the two interfaces is totally non-overlapping, and are consistent with
    the current chasms between kernel- and user-side debugging.

    Sure, in the future, it may make sense to teach the kernel-side (kgdb
    serial console) interface to manipulate userspace. But that will
    require a gdb extension. And it would not satisfy an unprivileged
    user's need to debug pure userspace (in a better way than current
    ptrace can).

    This is why I keep asking for specificity as to this "new framework"
    you imagine. Just sharing definitions such as kgdb_arch/kgdb_io but
    otherwise completely disconnected (separate channels)?


    > Extending kgdb to allow the use of it as if we used gdb locally would
    > certainly be interesting - and then you could drop into the kernel
    > anytime as well.

    (Is this a restatement of the "trick question" idea?)


    > > > We dont want to separate facilities for the same conceptual thing:
    > > > examining application state (be that in user-space and
    > > > kernel-space).

    > > This seems like a shallow sort of consistency. kgdb was added after
    > > ptrace existed -- why not extend ptrace instead to target the kernel?
    > > After all, it's "examining application state". The answer is that it
    > > doesn't make a heck of a lot of sense.
    >
    > kgdb simply used gdb's preferred way of remote debugging. That's
    > certainly the ugliest bit of it btw - but it's an externality to kgdb.
    > Had it extended ptrace it wouldnt have gdb compatibility.

    So, because of a constraint for gdb compatibility, you built a
    separate interface for kgdb vs. ptrace. Fine. Do you accept that,
    even if a hypothetical single channel existed for which kernel- and
    user-space debugging could occur, current gdb is not compatible with
    this? So by your own reasoning, such a facility should not be
    mandated as a "necessary first step".


    > [...] perf replaces oprofile functionally.

    (I'm told that it's not a strict superset from a functional point of
    view, FWIW, something about a larger selection of low level hardware
    counters.)

    > If the in-kernel gdb stub replaced kgdb functionally you'd hear no
    > complaints from me.

    Let's leave it as an idea for the future.


    - FChE


    \
     
     \ /
      Last update: 2009-12-08 23:03    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean