From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12043 Path: news.gmane.org!.POSTED!not-for-mail From: Andre McCurdy Newsgroups: gmane.linux.lib.musl.general Subject: Re: How to handle attempts to combine ARM Thumb with frame pointers? Date: Fri, 27 Oct 2017 17:48:28 -0700 Message-ID: References: <20171008032153.GH1627@brightrain.aerifal.cx> <20171025211623.GU15263@port70.net> <20171026170054.GA1627@brightrain.aerifal.cx> <20171026175411.GB1627@brightrain.aerifal.cx> <20171027003359.GD1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1509151736 16467 195.159.176.226 (28 Oct 2017 00:48:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 28 Oct 2017 00:48:56 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12056-gllmg-musl=m.gmane.org@lists.openwall.com Sat Oct 28 02:48:50 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1e8FIj-0002GE-HO for gllmg-musl@m.gmane.org; Sat, 28 Oct 2017 02:48:37 +0200 Original-Received: (qmail 28281 invoked by uid 550); 28 Oct 2017 00:48:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 28263 invoked from network); 28 Oct 2017 00:48:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=cvXTket4+MoQmUve/QHPflsWYYCBI7iJS6iptEgd+1U=; b=LEFPU/aQ8yhJfzg6y+hLV/jMNcNSdOs9knv3rnfSFZDOPiilJwFsPBsmepo6I6NlP6 eeniKrqg9QLXACY3nWli0j66L9dW9mRro0KV0JsMXjckQJ715z4ET2VCm31g2fIdfOg/ 0bWpPIjHs/n2W1E+FuSBj8tnugkduroDEkpz+fRpUjUznXIWTrpe0EaBSOu0hFClbNIQ sPRJ71tkzqDS2yw2djxE1q464i8Wm4laYU/eGcP1Hhu6CJQDzqfkxCXd3+TrWR3E4f3d lKzOaEhQWUtwZNLrH+RTCoCM595NWvxrEdvpQQDteOM3hu0/LeDqU5htLFiXArldJROR QRMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=cvXTket4+MoQmUve/QHPflsWYYCBI7iJS6iptEgd+1U=; b=fGNS+7XcuZJOlIv/kO5BgRRTzkID+mIdIIk3Y2hHzQ8IkjmJ+MxoyaQPpeoEAeL8W3 sPTbD56K0JGHzjxZAKmnR4CwnpoqkxXw85YFlZNkSkbH3DNTNGBfdGbkHT5p9vmHpWH1 0SlJE6GxBLzRYcmVOMVu8/HDVZz4UNA4Tp3l+grEbJYjnXKZRDl7xifzA2uW/wAE4Xif QeEaLxn9w2nU7bXk/QTuhb8zcraG9gqmjo5McCTIki6VfG5BpKkSMkCRkFS3aE0dK86R w28QYNrEfDSi/mXnxQbN0IDklmjjAvrMQhlLJgTcZid/Xy5y5MkEjmoHN1T8k6FCKxLW RKgw== X-Gm-Message-State: AMCzsaUxMv5g0ltSQsDN7ux9tSx1HxXFWr/HbRdyAvhQ9l3Iv1S02eHR aZP4ncR611lVRLIE5qoPRg5MvdwbqhD2oJnxiW2f8g== X-Google-Smtp-Source: ABhQp+TgHgvi4sxeyQNQXqg1h6Ws0VY8tWH+c8ufzrrpxT8OuPNrlsncJnpR7Lcd3dFr6Nv6xlc1W5/sK6CJeLBuct8= X-Received: by 10.28.11.138 with SMTP id 132mr1703503wml.89.1509151709551; Fri, 27 Oct 2017 17:48:29 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:12043 Archived-At: On Thu, Oct 26, 2017 at 7:17 PM, Andre McCurdy wrote: > On Thu, Oct 26, 2017 at 5:33 PM, Rich Felker 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.