[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ86T=WNryTRgQ=OOUn0XXy6B03jA0OfD+_DasxbEtTUVGGikw@mail.gmail.com>
Date: Mon, 9 Oct 2017 09:48:29 -0700
From: Andre McCurdy <armccurdy@...il.com>
To: musl@...ts.openwall.com
Subject: Re: How to handle attempts to combine ARM Thumb with frame pointers?
On Sat, Oct 7, 2017 at 8:21 PM, Rich Felker <dalias@...c.org> wrote:
> On Fri, Oct 06, 2017 at 05:53:38PM -0700, Andre McCurdy wrote:
>> When compiling for ARM Thumb or Thumb2 with frame pointers enabled (ie
>> -O0 or with -fno-omit-frame-pointer in CFLAGS) the frame pointer is
>> stored in r7, which leads to build errors ("error: r7 cannot be used
>> in asm here") whenever a syscall macro is included in a C function.
>> It's certainly a corner case, but one which I've run into recently.
>>
>> Would it be worth trying to catch this combination earlier and failing
>> from the configure script? It's not trivial to do reliably since I
>> think detecting whether or not frame pointers are going to be used by
>> examining CFLAGS means determining the effective optimisation level if
>> multiple -O0, -Os, etc options are given, together with the effective
>> outcome of potentially multiple -fno-omit-frame-pointer and
>> -fomit-frame-pointer options.
>>
>> I can work on a patch for the configure script but first wanted to
>> check what the philosophy is - should the configure script be trying
>> to catch every possible misconfiguration?
>
> At the core, I think this is a bug in GCC and clang, in the sense that
> they shouldn't be enforcing fixed registers in a way that conflicts
> with asm constraints.
I think gcc's current behaviour of aborting with an error is
reasonable. In this particular case, not using a frame pointer is the
only solution since the registers required to make a syscall can't be
changed. But there may be other cases where inline asm is using r7
arbitrarily and changing the asm to use a different register would be
a more appropriate solution. The user probably needs to make that
decision rather gcc.
> IIRC this was fixed on x86 for ebx and ebp a
> while back. But indeed if it's the state of things, that's how it is.
>
> If you do want to test for broken configurations, rather than
> hard-coding an assumption that some configuration is broken, you
> should test for it. This would look something like, if ARCH is arm,
> try compiling a trivial function with inline asm using r7 and see if
> it fails.
Yes, I came to the same conclusion after seeing the clang bug, which
seems to suggest that clang uses a frame pointer even with
optimisation enabled.
> If so, exit with an error or perhaps try adding
> -fomit-frame-pointer and retrying.
If we over-ride the user supplied CFLAGS then there's probably no need
to test the behaviour of the compiler - we can just force
-fomit-frame-pointer unconditionally when compiling for Thumb/Thumb2.
There's a slight complication though that if -fno-omit-frame-pointer
is present in the user supplied CFLAGS then adding
-fomit-frame-pointer to CFLAGS_AUTO won't over-ride it (since CFLAGS
appears on the final compiler command line after CFLAGS_AUTO).
Would it be OK for the configure script to append to CFLAGS? Or should
the configure script perhaps setup a new variable (CFLAGS_FORCE?)
which the Makefile would then add to CFLAGS_ALL after CFLAGS?
> I haven't tried any of this yet so
> I don't know how ugly/hackish it would be and whether it would be
> appropriate to include but it sounds like it could be.
>
> If clang generates broken code silently, though, I don't know any good
> way to test for that.
>
> Rich
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.
