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

[Andre McCurdy <armccurdy@gmail.com>]

On Thu, Oct 26, 2017 at 7:17 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Thu, Oct 26, 2017 at 5:33 PM, Rich Felker <dalias@libc.org> wrote:
>> 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.
>
> True. But these are all false positives. If any of these other reasons
> were to cause musl to use out of line syscalls then there's no real
> negative impact, apart from a missed optimisation.
>
> If I understand the glibc approach correctly it doesn't do any kind of
> test and always falls back to out of line syscalls for Thumb. Even if
> musl added a test which could generate a false positive it would be
> doing better than glibc.

For some additional context, this appears to be the glibc solution for
similar issues on x86:

  https://sourceware.org/bugzilla/show_bug.cgi?id=21029
  https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=3b33d6ed6096c1d20d05a650b06026d673f7399a

It seems to be based around a configure test which relies on the gcc
compile time error to determine whether or not it's possible to inline
syscalls.