[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e6f4c480-c4a5-11a8-b973-226c404199da@linaro.org>
Date: Thu, 26 Oct 2017 16:46:04 -0200
From: Adhemerval Zanella <adhemerval.zanella@...aro.org>
To: musl@...ts.openwall.com
Subject: Re: How to handle attempts to combine ARM Thumb with frame
pointers?
On 26/10/2017 15:00, Rich Felker 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 this might be a problem for musl where it does not provide
unwind information through CFI. For debugging with GLIBC, afaik GDB
will these information along libgcc unwind symbols to get correct call
frame and libc-do-syscall.S does seems to have correct CFI annotations.
>
> 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
>
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.
