From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12041 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: Thu, 26 Oct 2017 19:17:34 -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 1509070678 5630 195.159.176.226 (27 Oct 2017 02:17:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 27 Oct 2017 02:17:58 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12054-gllmg-musl=m.gmane.org@lists.openwall.com Fri Oct 27 04:17:54 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 1e7uDP-00085U-C0 for gllmg-musl@m.gmane.org; Fri, 27 Oct 2017 04:17:43 +0200 Original-Received: (qmail 22021 invoked by uid 550); 27 Oct 2017 02:17:47 -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 22000 invoked from network); 27 Oct 2017 02:17:47 -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=IIQAcVfUpHbbaIZj+4c/a1dsHpkcxwOWTOdKtlh7gUs=; b=fkaMdw7Yde3QauwpMXYYbR74jlUfcPgr2r2DZjN6phsm/u28WFT77N06kGpY4Xz4RA gmTTAdRXxsVWVokxLKF35wLl/cLWjgV5tsyYopO4O6Hl1uwD0AQoEtXwUHKP2cf08Be8 RBfKsjluYnRcRXpQcrCZF4R6CX3ac001kZFEZ09XavO1SB7slC4f4Sug9Mw1G6krCpXq C5TYn8HRQvYw2CkkQHY/ijb5JUCPwFgZwLltes+wCZcSZ2UsPcnACh2Y3fzqt3VB3Nzb GNqtPs8oZ0ykmyAVbpBMhPHVssNt9Q1cS6LNzDTWNWc6b+hYw1Dgw6UFHeZEN0/wmRPR XjLg== 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=IIQAcVfUpHbbaIZj+4c/a1dsHpkcxwOWTOdKtlh7gUs=; b=Rv3zDqBu79H7xDCnUC90dwHqY/ydiEVQxxDp3+locM+j1rpsj4TNY7qJm6bBPTNxzn 8WZldOF5Y+gEGkZ02oMC6gLixNuXDz/Zwx5TH4PzUj2UZnjtzbZsQR/LGu2713TbEFxI rZUMMsKAt8YCQTC72aleMXSackuKpuz4R70BGvRWPLB623fzn9l5p3HoatRML7i+tZDB 2YbuEhOtP5g5J1BxJPL8vw3UNHltoWlrGLQf/MTKniCExAXTf6Dst+3ea1fwaagQXq7X lXWrLr62Y4F+R2uToDnlMvGQKXcKFJczl66nOrqUxHPgh6pXK+xu8SMAC0DM4sR4GV4U wdRA== X-Gm-Message-State: AMCzsaV6TC+4cKcoI4k5hCVhH9+os8gX2kGp4FNiFpkTnTYcgHI3VJp1 3N5l40SiCO6NkIg8vOWQwzoAnehPNU4WCjOWNNY= X-Google-Smtp-Source: ABhQp+R3UphMtf9UrM1hU2BArJVc/CKLByOjoxlGNh72gw6zH5Z1TSAuuatf140dLx7eHIiD0lgmkm+2nIXdU8JeSIQ= X-Received: by 10.223.146.197 with SMTP id 63mr6391559wrn.180.1509070655243; Thu, 26 Oct 2017 19:17:35 -0700 (PDT) In-Reply-To: <20171027003359.GD1627@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12041 Archived-At: 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. > 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.