[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ86T=XxaAf9AjQDdVM5ux49T5Q2=ceu=_0_e87FKG1ND-Pr9g@mail.gmail.com>
Date: Thu, 26 Oct 2017 19:17:34 -0700
From: Andre McCurdy <armccurdy@...il.com>
To: musl@...ts.openwall.com
Subject: Re: How to handle attempts to combine ARM Thumb with frame pointers?
On Thu, Oct 26, 2017 at 5:33 PM, Rich Felker <dalias@...c.org> wrote:
> On Thu, Oct 26, 2017 at 11:51:17AM -0700, Andre McCurdy wrote:
>> >> 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).
>
> That's not really a reasonable assumption. There are all sorts of
> reasons the compiler might use a particular register even in a trivial
> function, for instrumentation, sanitizer, etc. type reasons.
True. But these are all false positives. If any of these other reasons
were to cause musl to use out of line syscalls then there's no real
negative impact, apart from a missed optimisation.
If I understand the glibc approach correctly it doesn't do any kind of
test and always falls back to out of line syscalls for Thumb. Even if
musl added a test which could generate a false positive it would be
doing better than glibc.
> Or, of
> course, as a frame pointer. The use of r7 is not what means we can't
> use the inline syscall asm. Rather, the compiler bug whereby it fails
> to let you use r7 in inline asm because it's doing the
> reservation-for-frame-pointer incorrectly (GCC), or where it silently
> generates wrong code (clang), is the reason that a workaround is
> needed in some cases. If GCC started handling the r7 constraint fine,
> spilling the frame pointer before the asm block and restoring it
> afterward so that the constraint could be met, there would not be any
> problem.
Doesn't enabling frame pointers imply any kind of guarantee that the
fp register is valid throughout the function? If the compiler is free
to spill and restore the fp register then I agree, but up to now I've
been assuming the compiler wasn't free to do that.
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.
