Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 Oct 2017 23:21:53 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: How to handle attempts to combine ARM Thumb with frame
 pointers?

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. 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. If so, exit with an error or perhaps try adding
-fomit-frame-pointer and retrying. 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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ