Re: Expansion of __builtin_frame_address

[Mark Mitchell <mark at codesourcery dot com>]

Richard Sandiford wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
>> I'd suggest we leave backtrace() aside, and just talk about
>> __builtin_frame_address(0), which does have well-defined semantics.
>> _b_f_a(0) is currently broken on ARM, and we all agree we should fix it.
> 
> I don't want to fan the flames here, but I'm not sure either statement
> is true.  Does __builtin_frame_address(0) really have well-defined
> semantics on a target for which the ABI does not specify a frame layout?
> I think that's Richard's point.

Thanks for explaining; after the latest messages from you and Richard
E., I understand the ARM doesn't have a standard frame layout.  I had
not realized that before.  However, even though there's not an ARM ABI
layout, if GCC uses a standard layout, then it would make sense for
_b_f_a(0) to return a pointer to that frame.  (_b_f_a(0) is a GCC
extension, so it can have a GCC-specific definition.)

If even that condition does not hold, then I agree that _b_f_a(0) should
just have undefined behavior on ARM.  We might even consider making it
an error to use it.  We should document in the manual that you can't use
_b_f_a(0) on reliably on some architectures.

If, however, there are plausible semantics we like for _b_f_a(0) on ARM,
then it doesn't seem to me that we should worry terribly much about
pessimizing the code by requiring a hard frame pointer.  Of course, it
would be better not to do so -- but if the only functions affected are
those that actually call _b_f_a(0), I doubt we'd be able to measure a
change in any real-world program.

Richard E. asked what possible uses this function might have.
Obviously, GLIBC's backtrace() function is one, though I guess that's a
weak example, in that we all agree one should really be using unwind
information.  (I still think it's somewhat valid, in that there are a
lot of people building GCC-only applications, and if backtrace() worked
in that case, it would be better than not working at all.)  The other
examples I can think of are also odd hacks; for example, checking for
stack overwrites, manually poking ones own return address pointer, or
manually grabbing saved registers from a caller, or some such.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713