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.