Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 27 Oct 2017 17:48:28 -0700
From: Andre McCurdy <>
Subject: Re: How to handle attempts to combine ARM Thumb with frame pointers?

On Thu, Oct 26, 2017 at 7:17 PM, Andre McCurdy <> wrote:
> On Thu, Oct 26, 2017 at 5:33 PM, Rich Felker <> 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:;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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.