[lkml]   [1999]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.2.8_ikd1.bz2
    Scott Lurndal wrote:

    > Kdb itself is mostly self-contained, with a couple of hooks in
    > traps.c, keyboard.c and serial.c. A general purpose mechanism
    > should be devised in traps.c to allow attaching and detaching handlers
    > for specific faults, and having multiple handlers for individual
    > faults (an implementation of which is found in the gdb-stubs patch,
    > if I recall correctly).

    My gdb patch is based on the gdb-stubs code from GNU. It has a function pointer
    that points to the gdb hook routine, but only one. So the handler has to be the
    same for all faults. It does get the error number and registers as a parameter
    so it can do pretty much whatever it wants to the machine state.

    > This would reduce further the impact of
    > kdb on the kernel source base. If the hooks were done right, the
    > entire kdb could be a loadable module with no run-time impact if
    > the module is not loaded.

    As presently implemented there would be a NULL pointer check in each trap
    handler to see if the gdb-stubs handler has hooked the function pointer.

    > Over the last 14 years of OS development, I've found having a
    > debugger in a production kernel to be invaluable (especially when
    > the run-time impact is limited to a small amount of RAM).

    I would love this. I could dial into a customer machine via a modem link and
    debug their kernel!

    -- Dave

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:51    [W:0.023 / U:72.080 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site