From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11986 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: Sat, 7 Oct 2017 23:21:53 -0400 Message-ID: <20171008032153.GH1627@brightrain.aerifal.cx> References: 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 1507432929 9464 195.159.176.226 (8 Oct 2017 03:22:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 8 Oct 2017 03:22:09 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11999-gllmg-musl=m.gmane.org@lists.openwall.com Sun Oct 08 05:22:05 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 1e12AG-0001pv-Ir for gllmg-musl@m.gmane.org; Sun, 08 Oct 2017 05:22:04 +0200 Original-Received: (qmail 1559 invoked by uid 550); 8 Oct 2017 03:22:08 -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 1535 invoked from network); 8 Oct 2017 03:22:07 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11986 Archived-At: On Fri, Oct 06, 2017 at 05:53:38PM -0700, Andre McCurdy wrote: > When compiling for ARM Thumb or Thumb2 with frame pointers enabled (ie > -O0 or with -fno-omit-frame-pointer in CFLAGS) the frame pointer is > stored in r7, which leads to build errors ("error: r7 cannot be used > in asm here") whenever a syscall macro is included in a C function. > It's certainly a corner case, but one which I've run into recently. > > Would it be worth trying to catch this combination earlier and failing > from the configure script? It's not trivial to do reliably since I > think detecting whether or not frame pointers are going to be used by > examining CFLAGS means determining the effective optimisation level if > multiple -O0, -Os, etc options are given, together with the effective > outcome of potentially multiple -fno-omit-frame-pointer and > -fomit-frame-pointer options. > > I can work on a patch for the configure script but first wanted to > check what the philosophy is - should the configure script be trying > to catch every possible misconfiguration? At the core, I think this is a bug in GCC and clang, in the sense that they shouldn't be enforcing fixed registers in a way that conflicts with asm constraints. IIRC this was fixed on x86 for ebx and ebp a while back. But indeed if it's the state of things, that's how it is. If you do want to test for broken configurations, rather than hard-coding an assumption that some configuration is broken, you should test for it. This would look something like, if ARCH is arm, try compiling a trivial function with inline asm using r7 and see if it fails. If so, exit with an error or perhaps try adding -fomit-frame-pointer and retrying. I haven't tried any of this yet so I don't know how ugly/hackish it would be and whether it would be appropriate to include but it sounds like it could be. If clang generates broken code silently, though, I don't know any good way to test for that. Rich