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/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:23 EST