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

[Andre McCurdy <armccurdy@gmail.com>]

On Thu, Oct 26, 2017 at 10:54 AM, Rich Felker <dalias@libc.org> wrote:
> 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@libc.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@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
>>
>> 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).

Yes, agreed. Just checking for the gcc comment isn't robust. But I
think there are other differences between the two cases which could be
detected reliably with a slightly more elaborate test, e.g. checking
for the use of r7 in the object code (assuming that for a trivial
function which just returns there's no reason that the compiler would
ever use of r7 except for a frame pointer).

  $ arm-linux-gnueabi-gcc -mthumb -O0 -c tst.c
  $ arm-linux-gnueabi-objdump -d -M reg-names-raw tst.o

    tst.o:     file format elf32-littlearm

    Disassembly of section .text:

    00000000 <a>:
       0:    b480          push    {r7}
       2:    af00          add    r7, sp, #0
       4:    bf00          nop
       6:    46bd          mov    r13, r7
       8:    f85d 7b04     ldr.w    r7, [r13], #4
       c:    4770          bx    r14


  $ arm-linux-gnueabi-gcc -mthumb -O1 -c tst.c
  $ arm-linux-gnueabi-objdump -d -M reg-names-raw  tst.o

    tst.o:     file format elf32-littlearm

    Disassembly of section .text:

    00000000 <a>:
       0:    4770          bx    r14


> 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.

As far as I understand it, clang doesn't correctly identify that
inline asm is using r7 and assumes that the frame pointer setup at
function entry is valid throughout the function.

  https://bugs.llvm.org/show_bug.cgi?id=34165