This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Expansion of __builtin_frame_address


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.

If I've understood the ARM case, then ARM is in the same boat as MIPS:
everything about the frame is an internal implementation detail.  I don't
think you can deference anything relative to __builtin_frame_address(0) on
MIPS and assume that it contains a particular value.

(Ironically, on MIPS, the soft frame pointer is if anything more stable
than the hard frame pointer.  The way things are set up in gcc, the soft
frame pointer always points to the bottom of the initial frame, whereas
in MIPS16 code, the hard frame pointer is offset from the soft frame
pointer by the size of the outgoing arguments.)

I'm probably going over old ground here, but:

    The frame is the area on the stack which holds local variables and saved
    registers.  The frame address is normally the address of the first word
    pushed on to the stack by the function.  However, the exact definition
    depends upon the processor and the calling convention.  If the processor
    has a dedicated frame pointer register, and the function has a frame,
    then @code{__builtin_frame_address} will return the value of the frame
    pointer register.

doesn't seem very well-defined from a predictability point of view,
since a user cannot in general know if "the function has a frame".
In some sense though, it argues that MarkS's patch isn't quite doing
what the documentation implies, since his patch effectively forces
_every_ caller of __builtin_frame_address to have a frame.

You can then argue about whether $30 on MIPS counts as "the _processor_
having a dedicated frame pointer register".  I'd say no, but...

(FWIW, MIPS is also like ARM in that MIPS gcc uses a different hard
frame pointer -- $17 -- for MIPS16 code.)

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]