This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Expansion of __builtin_frame_address
- From: Paul Brook <paul at codesourcery dot com>
- To: Richard Earnshaw <rearnsha at arm dot com>
- Cc: Daniel Jacobowitz <drow at false dot org>, gcc at gcc dot gnu dot org, Mark Shinwell <shinwell at codesourcery dot com>, Mark Mitchell <mark at codesourcery dot com>, James E Wilson <wilson at specifixinc dot com>
- Date: Fri, 2 Jun 2006 16:52:36 +0100
- Subject: Re: Expansion of __builtin_frame_address
- References: <4475C166.5090309@codesourcery.com> <20060602153520.GA28391@nevyn.them.org> <1149263062.14209.45.camel@pc960.cambridge.arm.com>
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