Enable the SystemZ back-end to lower FRAMEADDR and RETURNADDR, which previously would cause the back-end to crash. Currently, only a frame count of zero is supported.
Details
Diff Detail
Event Timeline
This implementation of -mattr=backchain is not quite compatible to GCC's -mbackchain flag: with GCC, if a function does not need any stack frame, -mbackchain by itself does *not* force allocation of a frame, as your patch does. -mbackchain only says that *if* a frame is allocated, then the frame's back chain slot is always kept valid. In addition, GCC keeps the back chain slot valid across alloca calls and other dynamic stack allocations, which your current implementation does not. (This latter is actually a bug, not just an incompatibility.)
(Note that if a function calls __builtin_frame_address or __builtin_return_address with a nonzero frame count, then GCC does force allocation of a stack frame. This in in turn is independent of -mbackchain, however.)
Now, if we actually implement -mattr=backchain, we should do it in a way compatible with GCC, and also enable it in clang via a -mbackchain command line option. However, I'm somewhat sceptical that this is really useful. (Note that for __builtin_frame_address and __builtin_return_address to be actually safe with larger count values, all of the program needs to be built with` -mbackchain` --- but this is not the case for any system-installed libraries on any current Linux distribution ...)
Hi Ulrich, thank you for your review. You are right that the non-zero frame traversal count is probably not very common. In the updated patch, I have removed the proposed -mattr=backchain changes. Is it better?