http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60109
--- Comment #4 from Thomas Preud'homme <thomas.preudhomme at arm dot com> --- Sorry for the late reply, I wasn't aware of this bug report until today. (In reply to Richard Earnshaw from comment #1) > This is an unresolvable problem. > > If we made __builtin_frame_address(N > 0) always return 0, then some useful > use cases for debugging would be excluded. > > On the other hand, it is impossible to know whether it will return a useful > value in other cases, since it is dependent on all code being: > a) built with the same instruction set (arm or thumb) Doesn't gcc use the same instruction set for a given compilation unit? I thought an application (without its libraries) would typically not mix instruction sets and therefore builtin_(return|frame)_address could be made to work within an application in 99% of the cases even if it breaks accross library calls (that could be compiled with different instruction set). > b) Having a consistent use of the frame pointer. It was my understanding that having a __builtin_frame_address disable frame pointer elimination base of the following comment in expand_builtin_return_addr (): "For a nonzero count, or a zero count with __builtin_frame_address, we require a stable offset from the current frame pointer to the previous one, so we must use the hard frame pointer, and we must disable frame pointer elimination." The fact that other compilation unit might not have a frame pointer because they were compiled with different compilers is ok. It would be nice that it works within a given compilation unit (as in the example in the initial email) though.
