From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11989 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: Mon, 9 Oct 2017 09:48:29 -0700 Message-ID: References: <20171008032153.GH1627@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 1507567729 19144 195.159.176.226 (9 Oct 2017 16:48:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 9 Oct 2017 16:48:49 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12002-gllmg-musl=m.gmane.org@lists.openwall.com Mon Oct 09 18:48:44 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 1e1bEN-0003ji-KT for gllmg-musl@m.gmane.org; Mon, 09 Oct 2017 18:48:39 +0200 Original-Received: (qmail 19625 invoked by uid 550); 9 Oct 2017 16:48:42 -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 19604 invoked from network); 9 Oct 2017 16:48:42 -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=f3oWAjku8l4c8WSmkdEJhzrOWFdspEp/wuvxkCiIQtE=; b=YuzkF4iOefs/Ts79mzO5HrKj6v7y3Hhd+uKawExB7hJaqKkawjSlvccb9n2eD0+Bap Qkaxn0STxiYHa3suxjfZ5zFm4UB2FRFdbF2l2ZCHSx4DYLzretrn+xPfNuaUwQr2ci4G T6DpAQ4Ne5CCyuM+94aLV/lCq6aPP66CXqtHfDwuxAShQmrdxcpA3Eib3HUwyoE8XFx+ gG//DvhaaHP3+5ft1agPbvyViDkLDKLQLi3wa/WanaMn/2kmX80Mh3tMj0ucODajyxmd vhURVSvMkkKgLQN/2ndCQyNek+8H+4eTdf1SiFrQxMrnkQEwsdU0kYOzkiT7ADStWLda bWQw== 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=f3oWAjku8l4c8WSmkdEJhzrOWFdspEp/wuvxkCiIQtE=; b=RXL+PkR3Ew6WIsExiMSgunna2DVjbXumtg+CMIwg+5VomWGi8HGl7foeLZZq2wFodu kf4g0IhH23zm5HPBEcK5HUi+3Jyjtg+LiYAK/brqAdw5jOEGkBgLfYBLdJypERweS2EG xH2IwShtX5OQKhUZJuw49wqx59R8TUGTplmJvpCvtbdjBhWbLOxcvg1Wr5tgbgh27SJT tuF6yYK6sPZ+HMWda0q9I1XtCHK1dqmO9swmP5AgKEKPO8AJemwvEV78nTDnlVgwip0v zc3uZiGeCTIiam93KIe7IkL+FQV2s86gz5RHjYOkY98hzK9Z1Uy7H98vPr2L+oGYrP0A w1Xg== X-Gm-Message-State: AMCzsaUfL2oiz08PtpMuVb+8r+wv7AjUSvHX40GlRup28N6HGHWLlTg/ JXJndHT64Fs3+3+Y3S0LZtwwPyePxonbrpV0j9kZmQ== X-Google-Smtp-Source: AOwi7QARuJjIG5pIpNEkDsCf1SwdW97bxpHXLigciguwShD0DnZNkW9LqPgwk+MVi+iYsWZRPNscscq+a+k6WxAMge4= X-Received: by 10.223.148.71 with SMTP id 65mr2362290wrq.263.1507567710305; Mon, 09 Oct 2017 09:48:30 -0700 (PDT) In-Reply-To: <20171008032153.GH1627@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:11989 Archived-At: On Sat, Oct 7, 2017 at 8:21 PM, Rich Felker wrote: > 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. I think gcc's current behaviour of aborting with an error is reasonable. In this particular case, not using a frame pointer is the only solution since the registers required to make a syscall can't be changed. But there may be other cases where inline asm is using r7 arbitrarily and changing the asm to use a different register would be a more appropriate solution. The user probably needs to make that decision rather gcc. > 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. Yes, I came to the same conclusion after seeing the clang bug, which seems to suggest that clang uses a frame pointer even with optimisation enabled. > If so, exit with an error or perhaps try adding > -fomit-frame-pointer and retrying. If we over-ride the user supplied CFLAGS then there's probably no need to test the behaviour of the compiler - we can just force -fomit-frame-pointer unconditionally when compiling for Thumb/Thumb2. There's a slight complication though that if -fno-omit-frame-pointer is present in the user supplied CFLAGS then adding -fomit-frame-pointer to CFLAGS_AUTO won't over-ride it (since CFLAGS appears on the final compiler command line after CFLAGS_AUTO). Would it be OK for the configure script to append to CFLAGS? Or should the configure script perhaps setup a new variable (CFLAGS_FORCE?) which the Makefile would then add to CFLAGS_ALL after CFLAGS? > 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