This is the mail archive of the 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

> __builtin_frame_address(n) is not required to work for any value other
> than n=0.  It's not clear what it means anyway on a function that
> eliminates the frame pointer.
> On ARM you *cannot* walk the stack frames without additional
> information.  Frames are private to each function and there is no
> defined format for the layout.  In particular the layout (and the frame
> pointer register) is different for ARM and Thumb code, but the two can
> be freely intermixed.
> The only chance you have for producing a backtrace() is to have
> unwinding information similar to that provided for exception unwinding.
> This would describe to the unwinder how that frames code is laid out so
> that it can unpick it.

I agree that in general you need ancillary information way to get a backtrace 
on Arm. However if you assume only Arm code code and -fno-omit-frame-pointer 
then you can walk the frames. Given this assumption I think it make sense to 
have _b_f_a(0) force the use of a frame pointer.

If you're implementing "proper" unwinding then I'd say you want to use an 
assembly function stub to determine the initial frame, rather than relying on 
a rather ill-defined gcc builtin function. In other words 
__builtin_frame_address is effectively useless, so we may as well make it 
consistent with historical use than try to optimize it.

Th background to this problem is we have a client who was upset when 
backtrace() "broke" with gcc4. For this particular client 
-marm -fno-omit-frame-pointer -mapcs-frame is an acceptable price to play for 
making backtrace() work.


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