mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Resolving ARM asm issues
Date: Thu, 5 Nov 2015 17:03:43 -0500	[thread overview]
Message-ID: <20151105220342.GA25556@brightrain.aerifal.cx> (raw)

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


                 reply	other threads:[~2015-11-05 22:03 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151105220342.GA25556@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).