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: __builtin_return_address for ARM


On Wed, 2009-02-25 at 12:27 +0000, Paul Brook wrote:
> In general it's impossible to make __builtin_return_address(N) to work for 
> N>0.

In any situation where you need to look beyond the current frame needs
agreement as to how the data required can be found.  That's going to
have an impact somehow compared with not permitting such access (if a
compiler knows that its frame is private then it can make all kinds of
optimizations that would be unacceptable otherwise).  

There are essentially two ways of exposing the information needed here:

1) You can lay out every frame according to an agreed model
2) You can provide every frame with a description that can be
interpreted to recover the required information.

Neither is free.  Case 1 is the worst since it severely impacts
performance for code even if it never makes use of your feature.  Case 2
is less bad in performance terms, but has a major impact on space in
that the descriptions can be non-trivial.

IMO any solution based on case 1 is unacceptable -- why should I
penalise my code for some feature that you want, but I'm completely
uninterested in?  Case 2 is only acceptable if constructed in such a way
that the additional information can be automatically discarded if it is
not required -- again, why should I penalise my code size numbers for a
feature I don't want.

In statically linked images it might be possible to determine that the
additional unwind information is unneeded and simply throw it away
during linking, but you can't do that in a shared library environment,
so we're back to the original sticking point: who gave you the right to
impose such a levy on my code?

Finally, gcc for ARM conforms to the ABI for the ARM Architecture --
that says what can and can't be assumed when linking code built from
other tool chains.  If you want a feature like this to work you'll need
to persuade the other toolchain developers to co-operate -- I think they
are extremely unlikely to be interested

R.



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