[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171026175411.GB1627@brightrain.aerifal.cx>
Date: Thu, 26 Oct 2017 13:54:11 -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 Thu, Oct 26, 2017 at 10:48:41AM -0700, Andre McCurdy wrote:
> On Thu, Oct 26, 2017 at 10:00 AM, Rich Felker <dalias@...c.org> wrote:
> > 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@...il.com> [2017-10-09 09:48:29 -0700]:
> >> >> 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:
> >> >>> 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
>
> Using r7 in inline asm together with frame pointers fails at build
> time with gcc, but not with clang.
>
> But perhaps an alternative way to detect whether the current
> combination of compiler + cflags is going to try to use frame pointers
> is to compile a trivial function to assembler and parse the output. I
> haven't tested clang, but gcc adds a helpful "frame_needed" comment
> which is easy to grep for.
This is not a good approach. It depends on specific compiler behavior
(text that's not part of the code) and thus has both false negatives
and false positives (it would break on compilers that allow you to use
r7 in asm constraints even when the compiler is using frame pointers).
I had forgotten about the clang issue though --- is it actually
silently generating bad code that doesn't respect the constraint? Or
something else? If so we probably need a separate way to detect it.
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.
