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

[Paul M. <le...@li...>]

On Mon, Jul 07, 2003 at 03:59:35PM +0100, Richard Curnow wrote:
> what.  So unless the app and all relevant libraries are compiled with
> -g, the backtracing doesn't proceed very far (actually, back as far as
> the first frame with no -g information.)
>=20
Well, based off of this, the kernel backtrace should still be accurate for
backtracing through the first stack frame, just not further. This is still
useful for tracking an implicit crash location with the type of crash
already determined ahead of time.

In my initial tests of this, I've been unwinding the stack early on, and
I hadn't noticed any oddities in the backtrace at that point -- though
it wasn't tracing very far back either.

Anyways, from the sounds of it, we'll need to have the symbol table availab=
le
in the kernel to actually make much additional use out of it (and trace back
much further -- due to unlinked strack frames). I'm not sure how feasible
this will be under 2.4, as it doesn't support a facility for this. Under 2.5
however, turning on CONFIG_KALLSYMS builds all of that in at link time, so
we should be able to do something there (other architectures use this for
things like print_symbol(), so that the symbol name can be decoded directly
on the initial backtrace without relying on ksymoops traces).

For 2.4, we're probably better off just not worrying about it, or simply
adding a comment into the existing backtrace code outlining its limited
usefulness.

At this point, 2.6 isn't far off, so I'd much rather focus on getting this
sort of stuff functional in 2.5 instead of spending more time on 2.4 (which
at this point should mostly be limited to stability fixes, in my opinion).