Messages in this thread | | | Date | Thu, 13 May 1999 08:46:05 -0500 | From | David Grothe <> | Subject | Re: 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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |