> __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. Paul
