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

[Rich Felker <dalias@libc.org>]

On Thu, Oct 26, 2017 at 02:48:11PM -0200, Adhemerval Zanella wrote:
> 
> 
> 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?

If you're compiling with frame pointers because you want them to be
present (and always valid) for debugging purposes or similar, there's
no way to achieve that while making syscalls -- and the most likely
place for a process to get stopped debugging is usually at a syscall.
Maybe this doesn't matter. It's not something we can change, just an
observation about a problem with the ABI, I think.

I think what we could do to ensure that compiling with frame pointers
otherwise works is add a configure test for use of r7 in inline asm,
and if it fails, -D something that would cause arch/arm/syscall_arch.h
not to define any syscall inlines but instead #define
SYSCALL_NO_INLINE which results in src/internal/syscall.h just using
the external __syscall function (which will of course clobber r7 for
the duration of the syscall).

Rich