From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12038 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 11:51:17 -0700 Message-ID: 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="UTF-8" X-Trace: blaine.gmane.org 1509043906 6580 195.159.176.226 (26 Oct 2017 18:51:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 26 Oct 2017 18:51:46 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12051-gllmg-musl=m.gmane.org@lists.openwall.com Thu Oct 26 20:51:41 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 1e7nFV-00084e-RS for gllmg-musl@m.gmane.org; Thu, 26 Oct 2017 20:51:25 +0200 Original-Received: (qmail 20308 invoked by uid 550); 26 Oct 2017 18:51:30 -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 20276 invoked from network); 26 Oct 2017 18:51:30 -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=G7L0vylHo+cShGPbrs2Kju53R9rAfuHvM7v6K5pMXdY=; b=WA8mWW74VcAhdYhCAMey9SvDnMRfIxbtVnA2UVu064avD7Xzu1HNPassoVCSrdxq01 M3NXs15A0sSGhDv1EGdyUGQtokwVtCupEq6bRQpZnRRZds2Rs4LnHDoicmdkIY0TGgEq yJxMYP9SaziBq9nKFWWBpSsHDv2gjIY6X7KKq7eOzwaN+qRA4z9syCTbXxWtgbA9uOt1 MixfA9GwL+Nui+AFWjVEmoE2A0BZtj4Br6Es3Rkmun/gdmO2bpsToI6XxSO1NUOxxQu/ NxFQ47krCw/CVbK/JsWBfiBu4jgF73i/XWWeHqQWrMbfVYTW6sBsWMbB43UTTwY1DhkQ 67Gg== 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=G7L0vylHo+cShGPbrs2Kju53R9rAfuHvM7v6K5pMXdY=; b=AMtbstsepn6w5BQaSifs5Eg1+zpncfBa3N1j5N5EP+6i+90vfKDeot9CyBMRwYGzxY X95xlJ2xKhrGMZcUHP15jvpdDmhT3z3iPtvf4T0TmznUSrBtIxy2tYl2V4xF3vUT2t4i GmiRJk3lzDnICZx6e/VJzQXWd9/4mVwTZtsJIGkkRQ2AiXIfaXoTY27bYBrZshrPPcg6 8v/ckWyYrxWAWe20tNBNJeRNHNgGy/l0bVaGulGbd0d3NH876MxikJTymzceHN6L+csz /CErBwJGvvMNygeyfvZpcZh7OqZwRzy/ZrbGub7Am6AlVXS0koNhIah5FsPPxM+f5Tvi FRHg== X-Gm-Message-State: AMCzsaUYsLx8Z2w7pChL0pldx/FbAqeu5kHD0sD7CWdNr1+NF8EKJ7Un 4ctPWW9scJG11/gx8g8UE6w0eIg5N0DXlXWN+Pq00g== X-Google-Smtp-Source: ABhQp+QZ536yVRLDjbmoN+19h9zfB0X+vhwjlIztRNuNgWUBAT8yi0L8bmTyqyC7YGPp4pOQuzRy2cpqKX+O5aQowAE= X-Received: by 10.28.11.138 with SMTP id 132mr2397322wml.89.1509043878428; Thu, 26 Oct 2017 11:51:18 -0700 (PDT) In-Reply-To: <20171026175411.GB1627@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12038 Archived-At: On Thu, Oct 26, 2017 at 10:54 AM, Rich Felker wrote: > On Thu, Oct 26, 2017 at 10:48:41AM -0700, Andre McCurdy wrote: >> On Thu, Oct 26, 2017 at 10:00 AM, Rich Felker wrote: >> > On Thu, Oct 26, 2017 at 02:48:11PM -0200, Adhemerval Zanella wrote: >> >> On 25/10/2017 19:16, Szabolcs Nagy wrote: >> >> > * Andre McCurdy [2017-10-09 09:48:29 -0700]: >> >> >> 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: >> >> >>> 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? >> >> > >> >> > glibc works this around in thumb mode by extern syscall asm >> >> > (of course it cannot guarantee that r7 is a frame pointer at >> >> > all times, an interrupt can observe r7 with syscall num in it, >> >> > i'm not sure if that's acceptable for users who compile with >> >> > frame-pointers, in musl there is some asm code which wont >> >> > have fp setup anyway). >> >> > >> >> > http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/arm/sysdep.h;h=6a64351cdd87c2041d639a17efc9f681262d5e3f;hb=HEAD#l335 >> >> >> >> Why do you mean by glibc strategy might not be acceptable? What >> >> kind of issue are you referring on interrupt case? >> > >> > If you're compiling with frame pointers because you want them to be >> > present (and always valid) for debugging purposes or similar, there's >> > no way to achieve that while making syscalls -- and the most likely >> > place for a process to get stopped debugging is usually at a syscall. >> > Maybe this doesn't matter. It's not something we can change, just an >> > observation about a problem with the ABI, I think. >> > >> > I think what we could do to ensure that compiling with frame pointers >> > otherwise works is add a configure test for use of r7 in inline asm, >> > and if it fails >> >> Using r7 in inline asm together with frame pointers fails at build >> time with gcc, but not with clang. >> >> 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). $ arm-linux-gnueabi-gcc -mthumb -O0 -c tst.c $ arm-linux-gnueabi-objdump -d -M reg-names-raw tst.o tst.o: file format elf32-littlearm Disassembly of section .text: 00000000 : 0: b480 push {r7} 2: af00 add r7, sp, #0 4: bf00 nop 6: 46bd mov r13, r7 8: f85d 7b04 ldr.w r7, [r13], #4 c: 4770 bx r14 $ arm-linux-gnueabi-gcc -mthumb -O1 -c tst.c $ arm-linux-gnueabi-objdump -d -M reg-names-raw tst.o tst.o: file format elf32-littlearm Disassembly of section .text: 00000000 : 0: 4770 bx r14 > I had forgotten about the clang issue though --- is it actually > silently generating bad code that doesn't respect the constraint? Or > something else? If so we probably need a separate way to detect it. As far as I understand it, clang doesn't correctly identify that inline asm is using r7 and assumes that the frame pointer setup at function entry is valid throughout the function. https://bugs.llvm.org/show_bug.cgi?id=34165