From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8812 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Resolving ARM asm issues Date: Thu, 5 Nov 2015 17:03:43 -0500 Message-ID: <20151105220342.GA25556@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1446761050 16820 80.91.229.3 (5 Nov 2015 22:04:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Nov 2015 22:04:10 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8825-gllmg-musl=m.gmane.org@lists.openwall.com Thu Nov 05 23:04:06 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZuSdZ-0001SQ-F0 for gllmg-musl@m.gmane.org; Thu, 05 Nov 2015 23:04:05 +0100 Original-Received: (qmail 13540 invoked by uid 550); 5 Nov 2015 22:04:01 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 13490 invoked from network); 5 Nov 2015 22:03:56 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8812 Archived-At: I've been working some more on resolving the issues with ARM asm. The constraints I'm trying to simultaneously satisfy are: 1. Compatibility with all relevant binutils/gas and clang internal-assembler versions. 2. Ability to produce arm or thumb code for the same asm source. 3. Avoiding tagging of object files as requiring a particular ISA level or hard float above the level the user intended to build for. The main places these are difficult are when we're conditionally (based on hwcap) using instructions that may not be available in the baseline ISA we're building for -- most notably, for setjmp/longjmp handling of call-saved floating point registers and TLS and atomics. Right now we are using .word to encode some instructions, which solves 1 and 3 but breaks 2. Based on my testing so far, the "right" solution seems to be setting and resetting .fpu/.arch _and_ using .eabi_attribute to clear unwanted attributes that may result. My findings are: - Clang does not output any unwanted attribute tags based on .arch or .fpu; it requires them to be specified manually. - Modern gas sets unwanted attributes automatically and does not clear the FPU-related ones when using .fpu softvfp after the relevant instructions, so manual clearing is necessary. - The last GPLv2 gas (2.17+) fails to properly drop the unwanted attributes even with expicit setting. I think we can either just ignore them being wrong or patch it. For setjmp, I have tested that all three accept the mnemonic: vstmia ip!, {d8-d15} once .fpu vfp is set. For atomics, using .arch armv7-a is needed in order to allow assembling them as thumb2. Both .arch armv4t and explicit reset of the unwanted attributes are needed to avoid wrong ISA-level tags. I still haven't done full testing on the fenv stuff, but since it only affects armhf, I'm not as concerned about having it work well with ancient toolchains, and it doesn't have to suppress vfp taging anyway. So I think we can just switch to the vfp/ual mnemonics there and have it work everywhere but on gas 2.17. Even after resolving all these issues, there's still a good bit of work to be done to make sure all the asm actually _can_ be built as thumb2. But I think we can resolve the blocking issues. Rich