On Friday 02 June 2006 16:44, Richard Earnshaw wrote: > On Fri, 2006-06-02 at 16:35, Daniel Jacobowitz wrote: > > On Fri, Jun 02, 2006 at 04:32:07PM +0100, Richard Earnshaw wrote: > > > On Fri, 2006-06-02 at 16:28, Paul Brook wrote: > > > > 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. > > > > > > No, in the general case you can't. Because ARM and Thumb frames are > > > laid out differently. In ARM code the frame pointer is in r11 (when > > > not eliminated); in thumb code it is in r7 (because r11 can't be used > > > in memory insns). > > > > I'm reading these two paragraphs and the two of you seem to be in > > violent agreement. Paul assumed ARM code only. > > Well, that's a pretty limiting assumption given that ARM and thumb code > can be freely intermixed. Indeed, I've often wondered if -Os should > default to Thumb code on CPUs that can support it (and thumb code can > corrupt the ARM frame register since it doesn't consider it to be > special in any way -- it's just a call-saved register). I've also > pondered making the compiler ignore -f[no-]omit-frame-pointer and to > only use one in cases where the stack is dynamically adjustable.
Ok, let me put it a different way. How is __builtin_frame_address(0) useful if you don't make these assumptions, and what would it be used for? For the record I agree that __builtin_return_address(0) has use and should not force a frame pointer. Paul
