Messages in this thread | | | Date | Tue, 26 Jan 1999 23:27:27 -0800 | From | "David S. Miller" <> | Subject | Re: Finally the 2.2.0 is out of sight :-). |
| |
From: "Anthony Barbachan" <barbacha@Hinako.AMBusiness.com> Date: Wed, 27 Jan 1999 00:46:55 -0500
>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/
| |