Re: How to handle attempts to combine ARM Thumb with frame pointers?

[Rich Felker <dalias@libc.org>]

On Thu, Oct 26, 2017 at 11:51:17AM -0700, Andre McCurdy wrote:
> >> But perhaps an alternative way to detect whether the current
> >> combination of compiler + cflags is going to try to use frame pointers
> >> is to compile a trivial function to assembler and parse the output. I
> >> haven't tested clang, but gcc adds a helpful "frame_needed" comment
> >> which is easy to grep for.
> >
> > This is not a good approach. It depends on specific compiler behavior
> > (text that's not part of the code) and thus has both false negatives
> > and false positives (it would break on compilers that allow you to use
> > r7 in asm constraints even when the compiler is using frame pointers).
> 
> Yes, agreed. Just checking for the gcc comment isn't robust. But I
> think there are other differences between the two cases which could be
> detected reliably with a slightly more elaborate test, e.g. checking
> for the use of r7 in the object code (assuming that for a trivial
> function which just returns there's no reason that the compiler would
> ever use of r7 except for a frame pointer).

That's not really a reasonable assumption. There are all sorts of
reasons the compiler might use a particular register even in a trivial
function, for instrumentation, sanitizer, etc. type reasons. Or, of
course, as a frame pointer. The use of r7 is not what means we can't
use the inline syscall asm. Rather, the compiler bug whereby it fails
to let you use r7 in inline asm because it's doing the
reservation-for-frame-pointer incorrectly (GCC), or where it silently
generates wrong code (clang), is the reason that a workaround is
needed in some cases. If GCC started handling the r7 constraint fine,
spilling the frame pointer before the asm block and restoring it
afterward so that the constraint could be met, there would not be any
problem.

Rich