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

[Szabolcs Nagy <nsz@port70.net>]

* Andre McCurdy <armccurdy@gmail.com> [2017-10-09 09:48:29 -0700]:
> On Sat, Oct 7, 2017 at 8:21 PM, Rich Felker <dalias@libc.org> wrote:
> > On Fri, Oct 06, 2017 at 05:53:38PM -0700, Andre McCurdy wrote:
> > 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?
> 

glibc works this around in thumb mode by extern syscall asm
(of course it cannot guarantee that r7 is a frame pointer at
all times, an interrupt can observe r7 with syscall num in it,
i'm not sure if that's acceptable for users who compile with
frame-pointers, in musl there is some asm code which wont
have fp setup anyway).

http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/arm/sysdep.h;h=6a64351cdd87c2041d639a17efc9f681262d5e3f;hb=HEAD#l335