From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12040 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: How to handle attempts to combine ARM Thumb with frame pointers? Date: Thu, 26 Oct 2017 20:33:59 -0400 Message-ID: <20171027003359.GD1627@brightrain.aerifal.cx> References: <20171008032153.GH1627@brightrain.aerifal.cx> <20171025211623.GU15263@port70.net> <20171026170054.GA1627@brightrain.aerifal.cx> <20171026175411.GB1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1509064456 32339 195.159.176.226 (27 Oct 2017 00:34:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 27 Oct 2017 00:34:16 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12053-gllmg-musl=m.gmane.org@lists.openwall.com Fri Oct 27 02:34:13 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 1e7sb8-0007Th-4o for gllmg-musl@m.gmane.org; Fri, 27 Oct 2017 02:34:06 +0200 Original-Received: (qmail 26399 invoked by uid 550); 27 Oct 2017 00:34:12 -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 26372 invoked from network); 27 Oct 2017 00:34:11 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12040 Archived-At: 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. 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. Rich