Re: crash when calling __builtin_return_address

[Paul Pluzhnikov]

Ulrich Lauther <ulrich.lauther@siemens.com> writes:

> : __builtin_return_address(0) should always work
>
> the parameter was "3". I now tried to first call __builtin_frame_address()
> and when that returns 0 to reduce the parameter. But then 
> __builtin_frame_address crashes.

Both "functions" assume that the code is compiled with a frame
pointer. They will both fail the same way if that's not the case.

> : With non-zero parameter, the work __builtin_return_address()
> : has to do to work correctly (and not crash) is so complicated,
> : that you should abandon all hope.
>
> But it seems to work without optimization;

Yes: so long as all code begins with 'pushq %rbp', you are ok.

> and without problems on an Intel processor 

Only when -fno-omit-frame-pointer is in effect, which it happens
to almost always be on x86, because otherwise x86 stack becomes
un-debuggable. On x86_64 debugger can easily unwind stack without
frame pointer (using unwind descriptors), so -O effectively turns
on -fomit-frame-pointer, and __builtin_{frame,return}_address() 
stop working.

> and on Suns.

SPARC is one of the easier platforms to unwind stack on.

> I need it to store the program counter at the time
> when a piece of memory is allocated for reporting later on memory leaks and
> their origin in my memory manager.

If it's your own memory manager, just pass the info (e.g. file,
line) into the allocation routine(s).

Alternatively, compile with '-O2 -fno-omit-frame-pointer'

> Is there another reliable way to access the program counter?

Yes: don't use __builtin_..._address() with parameter other than 0,
and use unwind descriptors to find callers. This latter part will
likely require a couple thousand lines of code (to decode dwarf3
info). Look in binutils-1.16.x/binutils/readelf.c
display_debug_frames() to get an idea of what's involved.

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.