Date: Fri, 27 Oct 2017 17:48:28 -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 7:17 PM, Andre McCurdy <armccurdy@...il.com> wrote: > 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. For some additional context, this appears to be the glibc solution for similar issues on x86: https://sourceware.org/bugzilla/show_bug.cgi?id=21029 https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=3b33d6ed6096c1d20d05a650b06026d673f7399a It seems to be based around a configure test which relies on the gcc compile time error to determine whether or not it's possible to inline syscalls.
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.