> 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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/