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.