Kernel debugger

[Casm]

I wonder if anybody has written a disassembler for their kernel debugger? It seems to be something which would be a lot of hassle now, but also something I might be grateful for later on. Years ago, when I was writing TSRs and device drivers for MS-DOS, I kept thinking, "I wish I had a debugger which could debug these in situ," but I was waiting for somebody else to write it. By the time I eventually did get round to it, DOS was near the end of its life.

So I am looking for your thoughts. What I have in mind is something akin to the DOS debug program, but linked into the kernel.

[OSwhatever]

I'm not sure a printed disassembly would help debugging as you usually don't really know where it is in your source code anyway. I would be more helpful if you also automatically searched the object file and got a print of the source as well. Well, at least print the source file name and line number.

If you have the possibility, remote debugging is usually better. Then you just can take the program counter where it crashed last time and do a full debug (stepping, disassembly etc)

[rdos]

Yes. Of course. That is first priority in OS-development!

Building the disassembler is one part of it, the other one is to integrate debugging support in the scheduler (and possibly fatal error handler).

I have this at several different levels.

1. A panic handler. This one is activated early in boot, and only dumps register contents and halts the system. No interaction possible. Does not show disassembled instructions.

2. A scheduler fault handler. This one stops the kernel when fatal exceptions and/or fatal scheduler conditions occur. It starts an interactive interface that can show registers on all cores in the system. It can also show memory contents, and selector mappings. Shows the current instruction.

3. A regular kernel debugger. This is a process in kernel which allows faulted / debugged threads to be inspected and debugged while the kernel is running. The kernel debugger cannot debug at source-level. Shows the current instruction.

4. The application debugger. The application debugger can debug device-drivers and kernel at source level using the usual application debugger interface. The only condition (right now, but this might change in the future) is that the debugger must start with an application, and can then trace syscalls into kernel / device-drivers.

[turdus]

Question already asked http://forum.osdev.org/viewtopic.php?t=21634
And the answer is absolutely yes. What if you run into a real machine only bug that does not show up on bochs with fancy debugger? How to debug if you do not have your own in your OS?
And I've also implemented these in my debugger, to get some ideas:
- instruction flow (you can follow the IP by pressing right arrow on highlighted jmp, jz, jc etc. and call instructions, left arrow goes back up to 8 levels)
- call stack trace
- object file dumper (like readelf)
- memory viewer (hex and text)
- memory usage visualizer and memory references (for fast access)
- nvram viewer
- root ramfs browser (obviously cannot follow mounts)
- syslog viewer (not a big deal, calls text viewer, but very handy)
- thread list (like top, but ordered by priority queues)
These are independent to my kernel and drivers, the debugger does not use any syscall and has it's own gdt, idt etc. And it's no more than 16k.

I can even debug eg. a double fault caused by user provided dsdt on real hardware quite comfortably
You may think it does not worth to implement so many feature in a debugger, but I assure you it does!