Re: [linuxsh-shmedia-dev] Backtrace in arch/sh64/kernel/traps.c

[Steve W. <sc...@ne...>]

On Mon, 7 Jul 2003, Richard Curnow wrote:

[in-kernel stack backtrace]

> However, as it stands, I'm not sure the output is useable.  When gdb
> backtraces user-land stacks, it has to use the CFI information in the
> executable to walk back up the stack.  Basically I believe this is
> because sh64 doesn't really have a fixed concept of stack frame layout

Right. The stack frames are not 'linked' together.

> Now I wouldn't expect the kernel's internal backtrace to deal with this,
> for a start, it doesn't know where the vmlinux executable is to look at
> the debug info, in fact it might not even be able to see its own vmlinux
> file.  So I think we must go for an approach where the stack is streamed
> out to the console and a ksymoops-like tool used offline to mangle it.

Is there any way to embed the kernel's symbol table in the kernel itself?

I ask because that's really all you need in order to make stack tracing
work on SH5. For an example, see how NetBSD's sh5 backend for the kernel
debugger does it (the symbol table _is_ available on NetBSD):

    http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/sh5/sh5/db_trace.c

By adding simple heuristics, you can also trace back through multiple
levels of exception frame (and print register contents while you're
there).

Cheers, Steve