Re: kgdb support in vanilla 2.6.2

[Andi Kleen]

Andrew Morton <akpm@xxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/