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

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 25/10/2017 19:16, Szabolcs Nagy wrote:
> * 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
> 

Why do you mean by glibc strategy might not be acceptable? What
kind of issue are you referring on interrupt case?