Messages in this thread |  | | Date | Tue, 05 Sep 2000 17:20:53 -0600 | From | "Jeff V. Merkey" <> | Subject | Linux/MANOS Kernel Debugger |
| |
I have written four OS's in my life (SAM, NetWare SMP, Wolf Mountain, MANOS). In each I always developed components in this order:
1. Debugger 2. Kernel 3. Memory Manager 4. I/O Subsystem.
I always would write a debugger first that would run in kernel mode. You need a special polling keyboard driver and a raw screen memory interface that's self contained and not dependent on the kernel in any way. On Intel, I would always use a task gate interface for the exception handlers since this allows you to debug a trashed stack. If someone trashes the stack, and you get a page fault, if there are not task gates over the exceptions, it results in a double fault (which turns into a triple fault when the double fault exception gets hit with a trashed stack and reboots).
To do this in Linux is very simple. Hook the exception handlers with task gates, create a TSS pool of free task gates, point the entry points into the MANOS debugger, (except the NMI gate -- it can be an interrupt gate since NMI interrrupts are prohibited by the hardware from ever nesting), and implement the task switch code in STARTUP.386 in MANOS as the gate entry stubs. Then the entire debugger could be moved en masse. At present, I decode CODEVIEW and NT symbols, but you will also notice that COFF symbol is also present in the debugger code -- the helper functions just need to be plugged. The entire debugger uses pluggable commands, register decodes, etc. and is easily moved to other processors than IA32. In fact, the IA32 disassembler in MANOS comes right out of GDB.
Since NMI's are not nested, I use the NMI xcall interrupt on the APICs to perform TLB shootdowns since an NMI will always cut through running code and reload CR3 on IA32. I also use the NMI interrupt to break into other processors to debug them -- a very useful feature for a processor hung in a loop.
There are special spin locks for the MANOS debugger -- it's fully SMP and can debug complex deadlocks and lock ordering. MANOS implements true sleep locks and has facilities for this, as well as semaphores.
I think it would not be hard to put this in. My problem is time and "debugging the debugger" in Linux. The codes at our site and anyone who wants to put it in is welcome to.
Also, MANOS is a Linux variant, so at any point, if Linus wants to "fire me" from it after it's posted and him and Alan take it over, be my guest.
:-)
Jeff
Kurt Roeckx wrote: > > On Tue, Sep 05, 2000 at 05:30:46PM +0200, Ingo Molnar wrote: > > > > On Tue, 5 Sep 2000, Jeff V. Merkey wrote: > > > > > A kernel debugger will reduce development costs. No one cares what's > > > underneath, [...] > > > > this is the point where IMO your argument gets flawed, and where you are > > apparently ignoring our arguments. With utmost respect, we *do* care about > > what's underneath. The health of what's underneath fueled and fuels the > > growth of Linux. I'd like to repeat it again: we cannot optimize for both > > the speed of FS driver development (your goal - correct me if i got it > > wrong), and long term health of the kernel proper itself (our goal), > > because in some areas (such as the inclusion of high complexity debugging > > facilities) they do contradict. (mostly they dont contradict) Long term > > health has priority - i cannot put it any simpler for you. Anyone who > > thinks driver development is the most important for Linux then thats a > > pretty shortsighted view IMO. > > A (better?) kernel debugger could help (certain) people to help improve > the long term health, because they can't (or don't want) to use what's > available, or just think they can't easely do it with them. It could help > certain people who are used to debug a problem in certain ways, to debug > it, where they have no idea how to do it with the current tools, because > nobody explained them how to use them for that problem. > > That debugger shouldn't be part of the main kernel, specially if it's so > complex. Trying to get the debugger to work might even find problems you > wouldn't easely find otherwise. > > Kurt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |