>And anybody could play with this, not only those who can afford a
>processor/system capable of virtual machines....
Umm, I'm not sure if this is possible, but perhaps a way of running
or promoting a regular process in or to kernel mode might be the
answer. This way gdb or any other debugger would be able to debug
kernel code. Maybe gdb could be ported to run as a kernel module?
Another possibility would be a kernel emulator or a way of running
a test kernel in user mode for testing and/or debugging.
Jakub and I always wanted to play around with implementing a %95
functional kernel GDB at the boot loader level.
It's very easy, the PROM on Sparcs provide all of the device I/O
etc. you need. It is a matter of:
1) Implementing stdio() using PROM callbacks.
2) Extracting e2fslib via PROM calls from SILO bootloader
3) Making fake headers for all of this, to get gdb to build
4) Linking it all together
Poof, full source level debugging even if the kernel is dead, live on
the machine.
I think real core dumps ala what most other systems do would be
helpful at times. But I also think it would make us lazy, so I
actually hope it never goes into the standard sources. Becomming
dependant upon debugging tools is a bad thing imho, because this
encourages less people to really understand the kernel and how it
works, and instead rely on the debugger to walk them to the source
where the problems are.
Back to my original point, I believe most other architectures (at
least Alpha and most x86's) wouldn't allow such an easy implementation
as I have described due to having less functional firmware.
One last point. Such schemes will never help us with the truly hairy
bugs. The ones which are all about careful timing, such that calling
any debug routine, or even trapping to some debugger breakpoint, would
remove all of the evidence. This is a second reason why we should
really encourage people to debug things the way we have always in the
Linux kernel, by using the source and not being dependant on fancy
debugging tools.
Ok, I think I've made my religious position clear :-)
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
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/