Re: __builtin_return_address for ARM

[Andrew Haley <aph at redhat dot com>]

Julian Brown wrote:
> On Thu, 26 Feb 2009 15:54:14 +0000
> Andrew Haley <aph@redhat.com> wrote:
> 
>> Paul Brook wrote:
>>>>   Well, but wouldn't it still be nice if
>>>> __builtin_return_address(N) was implemented for N>0 by libcalling
>>>> into the unwinder for you?  Obviously this would still have to
>>>> return NULL at runtime when you're running on a DW2 target without
>>>> any EH frame data present in memory (and I guess it wouldn't work
>>>> on SjLj targets either), but wouldn't it still be a nice
>>>> convenience feature for users?
>>> There are sufficiently many caveats and system specific bits of
>>> weirdness that you probably just have to know what you're doing (or
>>> rely on backtrace(3) to do it for you).
>>>
>>> IMHO builtins are for things that you can't do in normal C. So 
>>> __builtin_return_address(0) makes a lot of sense. Having it start
>>> guessing how to do N>0 much less so.
>> I suggest we could contribute a version of backtrace.c for ARM to
>> glibc. An example to follow is libc/sysdeps/ia64/backtrace.c.
> 
> GLIBC already knows how to do backtracing if the ARM-specific unwind
> tables are present (.ARM.exidx, etc.), using _Unwind_Backtrace.

I was about to say "On no it doesn't!" but I read your subsequent email.
:-)

> Unfortunately backtraces don't currently terminate cleanly if code
> without unwind data is reached: CodeSourcery are currently working on
> fixing the linker so that non-unwindable regions are marked properly,
> which we consider essential to making this feature usable.

Yeah, I noticed that when I implemented _Unwind_Backtrace.  It didn't matter
to me at the time because full unwind info is required for everything linked
with gcj.

Andrew.