Daniel Phillips wrote:
> On Wednesday 02 October 2002 11:22, Ingo Molnar wrote:
>
>>The attached (tested) patch modifies x86's dump_stack() to print out the
>>much friendlier backtrace.
>
> How about calling it backtrace(), since that's now what it is.
Sorry to go off topic but this tip is just too useful IMHO.
You can do the same in userspace with glibc. Details here:
http://www.iol.ie/~padraiga/backtrace.c
P?draig.
On Thu, 03 Oct 2002 09:31:06 +0100,
Padraig Brady <[email protected]> wrote:
>Sorry to go off topic but this tip is just too useful IMHO.
>You can do the same in userspace with glibc. Details here:
>http://www.iol.ie/~padraiga/backtrace.c
info libc, /backtrace.
Note that certain compiler optimisations may interfere with
obtaining a valid backtrace. Function inlining causes the inlined
function to not have a stack frame; tail call optimisation
replaces one stack frame with another; frame pointer elimination
will stop `backtrace' from interpreting the stack contents
correctly.
Most architectures compile with -fomit-frame-pointer (except for ARM
where RMK does it differently). Neither gdb not glibc can cope with
kernel code built with -fomit-frame-pointer. See the horrible
heuristics kdb has to apply to get any sort of backtrace on i386.
At 07:38 PM 10/3/2002 +1000, Keith Owens wrote:
>On Thu, 03 Oct 2002 09:31:06 +0100,
>Padraig Brady <[email protected]> wrote:
> >Sorry to go off topic but this tip is just too useful IMHO.
> >You can do the same in userspace with glibc. Details here:
> >http://www.iol.ie/~padraiga/backtrace.c
>
>info libc, /backtrace.
>
> Note that certain compiler optimisations may interfere with
> obtaining a valid backtrace. Function inlining causes the inlined
> function to not have a stack frame; tail call optimisation
> replaces one stack frame with another; frame pointer elimination
> will stop `backtrace' from interpreting the stack contents
> correctly.
>
>Most architectures compile with -fomit-frame-pointer (except for ARM
>where RMK does it differently). Neither gdb not glibc can cope with
>kernel code built with -fomit-frame-pointer. See the horrible
>heuristics kdb has to apply to get any sort of backtrace on i386.
IIRC, r~ once mentioned that it was going to get worse. He also mentioned
dwarf2 (sp) as a possible solution. Did you ever look into that?
-Mike
(I didn't. Elf->Dwarf transmogrification of kernel is way out of my league)
On Thu, Oct 03, 2002 at 12:03:27PM +0200, Mike Galbraith wrote:
> At 07:38 PM 10/3/2002 +1000, Keith Owens wrote:
> >Most architectures compile with -fomit-frame-pointer (except for ARM
> >where RMK does it differently). Neither gdb not glibc can cope with
> >kernel code built with -fomit-frame-pointer. See the horrible
> >heuristics kdb has to apply to get any sort of backtrace on i386.
>
> IIRC, r~ once mentioned that it was going to get worse. He also mentioned
> dwarf2 (sp) as a possible solution. Did you ever look into that?
There was the offer by someone to supply some code, which as per usual
came to nothing.
Therefore its just a bad rumour as far as I'm concerned. I can't do
everything, my days are full enough as it is.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
>>>>> On Thu, 03 Oct 2002 11:50:03 +0200, Keith Owens <[email protected]> said:
Keith> Most architectures compile with -fomit-frame-pointer (except
Keith> for ARM where RMK does it differently). Neither gdb not
Keith> glibc can cope with kernel code built with
Keith> -fomit-frame-pointer. See the horrible heuristics kdb has to
Keith> apply to get any sort of backtrace on i386.
Keith knows this, but just to be clear: there is no problem unwinding
across functions compiled with -fomit-frame-pointer on ia64. (Other
platforms could do the same if they took advantage of DWARF2 unwind
info.)
--david