Re: why no stacktrace?

[Andi Kleen <ak at muc dot de>]

ulrich.lauther@mchp.siemens.de (Ulrich Lauther) writes:

> > 
> > To provide a reliable back-trace, you must have a reliable stack
> > unwinder. The C ABI of most architectures does not have this built-in,
> > so gcc would have to emulate that function. For example, it could have
> > and alternative back-trace stack, and put a pointer to a string onto
> > that stack every time a function is entered, and pop it when the
> > function returns. Of course, that convention would not be honored by
> > the non-gcc-compiled functions (e.g. the C library), and it would add
> > noticable overhead.
> > 
> I am not a compiler specialist, but isn't the return address on the stack
> anyway?

The return address is not enough, you need a stack frame too, which is
often turned off because on x86 the another register can make a significant
performance difference. E.g. libraries are often compiled with 
-fomit-frame-pointer, so you wouldn't be able to trace back through a
callback in libraries you don't control. 

In theory you could get precise tracebacks using the DWARF2 unwinding
information used for C++ extensions, but as Martin points out they are
not part of the C ABI and generally not available in libraries (and have
a huge executable bloat penalty, just try to compile some C program
with -fexceptions and compare). Also I know of no backtracer currently
that can make use of the DWARF2 information on x86, even gdb cannot (it
instead uses some hacks to disassemble the function to find out the
stack frame length) 

The Linux kernel has the same problem. It works around by giving inprecise
callbacks. It just scans the stack for values that look like code addresses,
sanity checking has to be done by the human.

-Andi

-- 
This is like TV. I don't like TV.