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


On Fri, 2006-06-02 at 14:57, Mark Shinwell wrote:
> Richard Earnshaw wrote:
> > I'm not keen on this.  On some machines a frame pointer is *very*
> > expensive, both in terms of the code required to set it up, and the
> > resulting loss of a register which affects code quality (in addition, on
> > Thumb, the frame pointer can access much less data on the stack than the
> > stack pointer can, so code quality is affected even more).
> 
> Do you have anything in mind that would be a better default?  Is there
> something that could be used instead of hard_frame_pointer_rtx that
> will later expand to the correct frame address, but not necessarily force
> use of a frame pointer, for example?  (As far as I can tell,
> frame_pointer_rtx will not do at least in the ARM case, because it doesn't
> yield the same value.)
> 

Well in the past the ARM prologue code would copy the return address
into a pseudo if the body of the function invoked
__builtin_return_address, then the body of the code just used the
psuedo.  Somebody found a reason to change this, but I can't remember
why.

> If the hard frame pointer is forced by default, then targets which are
> particularly badly affected can simply define INITIAL_FRAME_ADDRESS_RTX.
> Since such targets would presumably not have to force reload to keep
> the frame pointer, then definitions of such macros would not need to
> be side-effecting (in the way described earlier in this thread) and thus
> be satisfactory.
> 
> > I can see no argument for a frame pointer being *required* for getting
> > the return address.  We didn't have to do this in the past, so I think
> > it is wrong to require that we do it now.
> 
> Currently, the code does require a frame pointer in all except the
> count == 0 case, and as far as that particular case goes I get the
> impression that it would have been treated in the same way had this
> glibc backtrace function been noticed last year.  This may be a mistaken
> impression though.

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

R.


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