Messages in this thread | | | Subject | Re: kgdb support in vanilla 2.6.2 | From | Andi Kleen <> | Date | 05 Feb 2004 04:11:34 +0100 |
| |
Andrew Morton <akpm@osdl.org> writes:
> need to take a look at such things and really convice ourselves that > they're worthwhile. Personally, I'd only be interested in the basic stub.
What I found always extremly ugly in the i386 stub was that it uses magic globals to talk to the page fault handler. For the x86-64 version I replaced that by just using __get/__put_user in the memory accesses, which is much cleaner. I would suggest doing that for i386 too.
Also what's also ugly in i386 is that it uses ugly hooks in traps.c/fault.c. On x86-64 I instead added generic notifiers (see include/asm-x86_64/die.h and notify_die in arch/x86_64/kernel/traps.c) where both kdb and kgdb and possibly dprobes and other debuggers can hook in without conflicting patches for the same files from everybody. I would strongly suggest to adopt such a generic framework for i386 too to clean up the core kernel <-> debugger interaction. As soon as this frame work is in just dropping the stub is is very clean.
The x86-64 version should be pretty simple to port to i386 if someone is interested ...
Another issue is that for modern gdb and frame pointer less debugging with dwarf2 we really need dwarf2 cfi annotation on i386 too. It is not as ugly as it used to be because newer binutils have much nicer to use .cfi_* mnemonics to generate the dwarf2 unwind table. x86-64 uses that now thanks to Jim Houston. It only works with uptodate binutils, but I guess that's a reasonable requirement. It's a bit intrusive in entry.S, but not too bad compared to the old way (take a look at arch/i386/kernel/vsyscall-sysenter.S to see how the old way looks like) Having the dwarf2 unwind information in the kernel vmlinux is useful even independent of kgdb for other tools that look at crash dumps.
-Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |