status of armhf asm with VFP instructions

status of armhf asm with VFP instructions

[Szabolcs Nagy]

it is not possible to write arm asm in a way that pleases all
assemblers, here is a summary of the problems relevant to musl:

some instructions can be written in several ways since UAL
(= unified assembler language) was introduced to unify arm
and thumb instruction mnemonics.

in case of armhf VFP instructions musl uses the following ones
in hand written asm:

 hex       ual         old

 eeb1XacX  vsqrt.f32   fsqrts
 eeb1XbcX  vsqrt.f64   fsqrtd
 eeb0XacX  vabs.f64    fabss
 eeb0XbcX  vabs.f64    fabsd
 eef1Xa10  vmrs fpscr  mrc p10,7,..
 eee1Xa10  vmsr fpscr  mcr p10,7,..

the issues:

(1) binutils gas rejects UAL VFP instructions unless either
the -mfpu=<vfp variant> option is passed or the asm source
has '.fpu <vfp variant>' directive, the old names work though
(if the target is hard float).  A gcc toolchain built
--with-float=hard but without --with-fpu=<vfp variant> does not
pass -mfpu to the assembler.

(2) Most UAL mnemonics were added in binutils 2.18, older
binutils only supports the old syntax.  Some UAL mnemonics were
added later, vmrs and vmsr only appear in binutils 2.21
(released in 2010).

(3) The clang assembler does not support old mnemonics in general
but includes a few exceptions (e.g. fabs and fsqrt are supported,
but not the mrc or mcr coprocessor instructions).

Using UAL asm is the clean solution, but then to fix (1) we
should have .fpu directives in the asm files.

However the conflict between (2) and (3) means that fenv code
using vmrs and vmsr either drops support for old binutils gas
or the clang assembler.

Re: status of armhf asm with VFP instructions

[Rich Felker]

On Fri, Oct 16, 2015 at 12:33:20AM +0200, Szabolcs Nagy wrote:
> it is not possible to write arm asm in a way that pleases all
> assemblers, here is a summary of the problems relevant to musl:
> 
> some instructions can be written in several ways since UAL
> (= unified assembler language) was introduced to unify arm
> and thumb instruction mnemonics.
> 
> in case of armhf VFP instructions musl uses the following ones
> in hand written asm:
> 
>  hex       ual         old
> 
>  eeb1XacX  vsqrt.f32   fsqrts
>  eeb1XbcX  vsqrt.f64   fsqrtd
>  eeb0XacX  vabs.f64    fabss
>  eeb0XbcX  vabs.f64    fabsd
>  eef1Xa10  vmrs fpscr  mrc p10,7,..
>  eee1Xa10  vmsr fpscr  mcr p10,7,..
> 
> the issues:
> 
> (1) binutils gas rejects UAL VFP instructions unless either
> the -mfpu=<vfp variant> option is passed or the asm source
> has '.fpu <vfp variant>' directive, the old names work though
> (if the target is hard float).  A gcc toolchain built
> --with-float=hard but without --with-fpu=<vfp variant> does not
> pass -mfpu to the assembler.
> 
> (2) Most UAL mnemonics were added in binutils 2.18, older
> binutils only supports the old syntax.  Some UAL mnemonics were
> added later, vmrs and vmsr only appear in binutils 2.21
> (released in 2010).
> 
> (3) The clang assembler does not support old mnemonics in general
> but includes a few exceptions (e.g. fabs and fsqrt are supported,
> but not the mrc or mcr coprocessor instructions).
> 
> Using UAL asm is the clean solution, but then to fix (1) we
> should have .fpu directives in the asm files.
> 
> However the conflict between (2) and (3) means that fenv code
> using vmrs and vmsr either drops support for old binutils gas
> or the clang assembler.

It seems we're already using the new forms vsqrt and vabs in
src/math/armhf/*.s. So using vmrs/vmsr presumably will not break
support for any toolchains that work now.

I think the reason this went unnoticed for so long is that Aboriginal
Linux (the only real user of the ancient binutils, due to GPL v2 vs v3
issues) does not use the armhf ABI at all; it only targets standard
EABI for which musl does not use any math/fenv asm.

So I'm ok with the fpu-related changes proposed, but I'm not sure what
to do about UAL issues elsewhere. Right now we have a lot of files
with instructions written as .word in them which is a mess and which
precludes Cortex-M (thumb2-only) targets. These are files which need
to be built even on non-hf, so changing them presumably will break
support for old binutils. As a workaround, users needing old binutils
could perhaps misuse the ASM_CMD var in the Makefile to run a sed
script that replaces UAL with old-syntax asm. Or someone could patch
the old binutils to accept UAL...

Rich

Re: status of armhf asm with VFP instructions

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2015-10-15 18:44:25 -0400]:
> On Fri, Oct 16, 2015 at 12:33:20AM +0200, Szabolcs Nagy wrote:
> > it is not possible to write arm asm in a way that pleases all
> > assemblers, here is a summary of the problems relevant to musl:
> > 
> > some instructions can be written in several ways since UAL
> > (= unified assembler language) was introduced to unify arm
> > and thumb instruction mnemonics.
> > 
> > in case of armhf VFP instructions musl uses the following ones
> > in hand written asm:
> > 
> >  hex       ual         old
> > 
> >  eeb1XacX  vsqrt.f32   fsqrts
> >  eeb1XbcX  vsqrt.f64   fsqrtd
> >  eeb0XacX  vabs.f64    fabss
> >  eeb0XbcX  vabs.f64    fabsd
> >  eef1Xa10  vmrs fpscr  mrc p10,7,..
> >  eee1Xa10  vmsr fpscr  mcr p10,7,..

sorry, for reading/writing fpscr fmrx/fmxr can be used in the
old syntax instead of vmrs/vmsr, but clang does not know
those names.

> > the issues:
> > 
> > (1) binutils gas rejects UAL VFP instructions unless either
> > the -mfpu=<vfp variant> option is passed or the asm source
> > has '.fpu <vfp variant>' directive, the old names work though
> > (if the target is hard float).  A gcc toolchain built
> > --with-float=hard but without --with-fpu=<vfp variant> does not
> > pass -mfpu to the assembler.
> > 
> > (2) Most UAL mnemonics were added in binutils 2.18, older
> > binutils only supports the old syntax.  Some UAL mnemonics were
> > added later, vmrs and vmsr only appear in binutils 2.21
> > (released in 2010).
> > 
> > (3) The clang assembler does not support old mnemonics in general
> > but includes a few exceptions (e.g. fabs and fsqrt are supported,
> > but not the mrc or mcr coprocessor instructions).
> > 
> > Using UAL asm is the clean solution, but then to fix (1) we
> > should have .fpu directives in the asm files.
> > 
> > However the conflict between (2) and (3) means that fenv code
> > using vmrs and vmsr either drops support for old binutils gas
> > or the clang assembler.
> 
> It seems we're already using the new forms vsqrt and vabs in
> src/math/armhf/*.s. So using vmrs/vmsr presumably will not break
> support for any toolchains that work now.
> 

vmrs/vmsr can break on old binutils versions (2.18 - 2.20) and
2.20 is not that ancient.. is that ok?

> I think the reason this went unnoticed for so long is that Aboriginal
> Linux (the only real user of the ancient binutils, due to GPL v2 vs v3
> issues) does not use the armhf ABI at all; it only targets standard
> EABI for which musl does not use any math/fenv asm.
> 
> So I'm ok with the fpu-related changes proposed, but I'm not sure what
> to do about UAL issues elsewhere. Right now we have a lot of files
> with instructions written as .word in them which is a mess and which
> precludes Cortex-M (thumb2-only) targets. These are files which need
> to be built even on non-hf, so changing them presumably will break
> support for old binutils. As a workaround, users needing old binutils
> could perhaps misuse the ASM_CMD var in the Makefile to run a sed
> script that replaces UAL with old-syntax asm. Or someone could patch
> the old binutils to accept UAL...
> 

most likely ual is the long term solution.

maybe it is best to switch to ual and then write that script
if ppl with old binutils run into issues.

Re: status of armhf asm with VFP instructions

[Szabolcs Nagy]

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

* Szabolcs Nagy <nsz@port70.net> [2015-10-16 01:16:07 +0200]:
> * Rich Felker <dalias@libc.org> [2015-10-15 18:44:25 -0400]:
> > It seems we're already using the new forms vsqrt and vabs in
> > src/math/armhf/*.s. So using vmrs/vmsr presumably will not break
> > support for any toolchains that work now.
> > 
> 
> vmrs/vmsr can break on old binutils versions (2.18 - 2.20) and
> 2.20 is not that ancient.. is that ok?
> 

attached the old armhf patch with updated commit message.

[-- Attachment #2: 0001-fix-armhf-asm-to-use-.fpu-vfp-and-UAL-mnemonics.patch --]
[-- Type: text/x-diff, Size: 3509 bytes --]

From 542d4003a60320ac0446b156681c59cbc19dd6a1 Mon Sep 17 00:00:00 2001
From: Szabolcs Nagy <nsz@port70.net>
Date: Tue, 21 Jul 2015 20:00:03 +0000
Subject: [PATCH] fix armhf asm to use .fpu vfp and UAL mnemonics

(1) Some armhf gcc toolchains (built with --with-float=hard but without
--with-fpu=vfp*) do not pass -mfpu=vfp to the assembler and then binutils
rejects the UAL mnemonics for VFP unless there is an .fpu vfp directive
in the asm source.

(2) binutils <= 2.17 does not support UAL VFP syntax, and vmrs/vmsr insns
are only recognised in binutils >= 2.21.

(3) clang builtin assembler does not support the old mnemonics (except a
few with warnings).

Added .fpu vfp directive to all armhf asm which use VFP instructions
to solve (1) (only backward compatible VFPv1 instructions are used),
dropped support for binutils < 2.21 and replaced mcr/mrc with vmsr/vmrs.
The generated code should not be changed by this commit.
---
 src/fenv/armhf/fenv.s  | 22 ++++++++++++----------
 src/math/armhf/fabs.s  |  1 +
 src/math/armhf/fabsf.s |  1 +
 src/math/armhf/sqrt.s  |  1 +
 src/math/armhf/sqrtf.s |  1 +
 5 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/src/fenv/armhf/fenv.s b/src/fenv/armhf/fenv.s
index 387234b..2621422 100644
--- a/src/fenv/armhf/fenv.s
+++ b/src/fenv/armhf/fenv.s
@@ -1,17 +1,19 @@
+.fpu vfp
+
 .global fegetround
 .type fegetround,%function
 fegetround:
-	mrc p10, 7, r0, cr1, cr0, 0
+	vmrs r0, fpscr
 	and r0, r0, #0xc00000
 	bx lr
 
 .global __fesetround
 .type __fesetround,%function
 __fesetround:
-	mrc p10, 7, r3, cr1, cr0, 0
+	vmrs r3, fpscr
 	bic r3, r3, #0xc00000
 	orr r3, r3, r0
-	mcr p10, 7, r3, cr1, cr0, 0
+	vmsr fpscr, r3
 	mov r0, #0
 	bx lr
 
@@ -19,7 +21,7 @@ __fesetround:
 .type fetestexcept,%function
 fetestexcept:
 	and r0, r0, #0x1f
-	mrc p10, 7, r3, cr1, cr0, 0
+	vmrs r3, fpscr
 	and r0, r0, r3
 	bx lr
 
@@ -27,9 +29,9 @@ fetestexcept:
 .type feclearexcept,%function
 feclearexcept:
 	and r0, r0, #0x1f
-	mrc p10, 7, r3, cr1, cr0, 0
+	vmrs r3, fpscr
 	bic r3, r3, r0
-	mcr p10, 7, r3, cr1, cr0, 0
+	vmsr fpscr, r3
 	mov r0, #0
 	bx lr
 
@@ -37,16 +39,16 @@ feclearexcept:
 .type feraiseexcept,%function
 feraiseexcept:
 	and r0, r0, #0x1f
-	mrc p10, 7, r3, cr1, cr0, 0
+	vmrs r3, fpscr
 	orr r3, r3, r0
-	mcr p10, 7, r3, cr1, cr0, 0
+	vmsr fpscr, r3
 	mov r0, #0
 	bx lr
 
 .global fegetenv
 .type fegetenv,%function
 fegetenv:
-	mrc p10, 7, r3, cr1, cr0, 0
+	vmrs r3, fpscr
 	str r3, [r0]
 	mov r0, #0
 	bx lr
@@ -57,6 +59,6 @@ fesetenv:
 	cmn r0, #1
 	moveq r3, #0
 	ldrne r3, [r0]
-	mcr p10, 7, r3, cr1, cr0, 0
+	vmsr fpscr, r3
 	mov r0, #0
 	bx lr
diff --git a/src/math/armhf/fabs.s b/src/math/armhf/fabs.s
index 2bdebff..8a705e1 100644
--- a/src/math/armhf/fabs.s
+++ b/src/math/armhf/fabs.s
@@ -1,3 +1,4 @@
+.fpu vfp
 .text
 .global fabs
 .type   fabs,%function
diff --git a/src/math/armhf/fabsf.s b/src/math/armhf/fabsf.s
index 35c720f..2c7beb6 100644
--- a/src/math/armhf/fabsf.s
+++ b/src/math/armhf/fabsf.s
@@ -1,3 +1,4 @@
+.fpu vfp
 .text
 .global fabsf
 .type   fabsf,%function
diff --git a/src/math/armhf/sqrt.s b/src/math/armhf/sqrt.s
index 99fe64b..90f74a9 100644
--- a/src/math/armhf/sqrt.s
+++ b/src/math/armhf/sqrt.s
@@ -1,3 +1,4 @@
+.fpu vfp
 .text
 .global sqrt
 .type   sqrt,%function
diff --git a/src/math/armhf/sqrtf.s b/src/math/armhf/sqrtf.s
index 9ea519f..91d8ad6 100644
--- a/src/math/armhf/sqrtf.s
+++ b/src/math/armhf/sqrtf.s
@@ -1,3 +1,4 @@
+.fpu vfp
 .text
 .global sqrtf
 .type   sqrtf,%function
-- 
2.4.1

Re: status of armhf asm with VFP instructions

[Rich Felker]

On Fri, Oct 16, 2015 at 01:16:07AM +0200, Szabolcs Nagy wrote:
> > > the issues:
> > > 
> > > (1) binutils gas rejects UAL VFP instructions unless either
> > > the -mfpu=<vfp variant> option is passed or the asm source
> > > has '.fpu <vfp variant>' directive, the old names work though
> > > (if the target is hard float).  A gcc toolchain built
> > > --with-float=hard but without --with-fpu=<vfp variant> does not
> > > pass -mfpu to the assembler.
> > > 
> > > (2) Most UAL mnemonics were added in binutils 2.18, older
> > > binutils only supports the old syntax.  Some UAL mnemonics were
> > > added later, vmrs and vmsr only appear in binutils 2.21
> > > (released in 2010).
> > > 
> > > (3) The clang assembler does not support old mnemonics in general
> > > but includes a few exceptions (e.g. fabs and fsqrt are supported,
> > > but not the mrc or mcr coprocessor instructions).
> > > 
> > > Using UAL asm is the clean solution, but then to fix (1) we
> > > should have .fpu directives in the asm files.
> > > 
> > > However the conflict between (2) and (3) means that fenv code
> > > using vmrs and vmsr either drops support for old binutils gas
> > > or the clang assembler.
> > 
> > It seems we're already using the new forms vsqrt and vabs in
> > src/math/armhf/*.s. So using vmrs/vmsr presumably will not break
> > support for any toolchains that work now.
> > 
> 
> vmrs/vmsr can break on old binutils versions (2.18 - 2.20) and
> 2.20 is not that ancient.. is that ok?

2.20 seems to be from 2009 and 2.21 from 2010, despite the fake 2011
timestamps on the GNU ftp site. See:

https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=20835820a172906a3b24b2551d5eeb03e3d8dc32
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f195a4076f78b60965b4b95561c76d743fe7e1c7

This is not ancient, but also not recent. Are there arm-based distros
using it, or any particular reason we should care? 2.17 is interesting
to some people as the last-gplv2 version, but newer-but-old stuff
seems less interesting.

> > I think the reason this went unnoticed for so long is that Aboriginal
> > Linux (the only real user of the ancient binutils, due to GPL v2 vs v3
> > issues) does not use the armhf ABI at all; it only targets standard
> > EABI for which musl does not use any math/fenv asm.
> > 
> > So I'm ok with the fpu-related changes proposed, but I'm not sure what
> > to do about UAL issues elsewhere. Right now we have a lot of files
> > with instructions written as .word in them which is a mess and which
> > precludes Cortex-M (thumb2-only) targets. These are files which need
> > to be built even on non-hf, so changing them presumably will break
> > support for old binutils. As a workaround, users needing old binutils
> > could perhaps misuse the ASM_CMD var in the Makefile to run a sed
> > script that replaces UAL with old-syntax asm. Or someone could patch
> > the old binutils to accept UAL...
> > 
> 
> most likely ual is the long term solution.
> 
> maybe it is best to switch to ual and then write that script
> if ppl with old binutils run into issues.

That sounds like it might be the best option. I don't like dropping
support for old stuff, but ARM really made a mess of this by making a
new gratuitously incompatible asm syntax and encouraging tools not to
support the old syntax (and particularly, not to support generating
thumb2 from it, despite the fact that there's no fundamental reason it
couldn't be done).

BTW for other things I think we need some sort of syntax directive to
tell the assembler we'll be using the unified syntax -- is this right?
Do you know what the minimum gas version that supports this directive
is?

Rich

Re: status of armhf asm with VFP instructions

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2015-10-15 20:00:56 -0400]:
> On Fri, Oct 16, 2015 at 01:16:07AM +0200, Szabolcs Nagy wrote:
> > most likely ual is the long term solution.
> > 
> > maybe it is best to switch to ual and then write that script
> > if ppl with old binutils run into issues.
> 
> That sounds like it might be the best option. I don't like dropping
> support for old stuff, but ARM really made a mess of this by making a
> new gratuitously incompatible asm syntax and encouraging tools not to
> support the old syntax (and particularly, not to support generating
> thumb2 from it, despite the fact that there's no fundamental reason it
> couldn't be done).
> 
> BTW for other things I think we need some sort of syntax directive to
> tell the assembler we'll be using the unified syntax -- is this right?
> Do you know what the minimum gas version that supports this directive
> is?

.syntax unified (binutils supports it since 2005).

and the default is divided syntax
(so inline asm has to use divided syntax or
".sytax unified"
...
".syntax divided")

Re: status of armhf asm with VFP instructions

[Rich Felker]

On Fri, Oct 16, 2015 at 02:33:13AM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2015-10-15 20:00:56 -0400]:
> > On Fri, Oct 16, 2015 at 01:16:07AM +0200, Szabolcs Nagy wrote:
> > > most likely ual is the long term solution.
> > > 
> > > maybe it is best to switch to ual and then write that script
> > > if ppl with old binutils run into issues.
> > 
> > That sounds like it might be the best option. I don't like dropping
> > support for old stuff, but ARM really made a mess of this by making a
> > new gratuitously incompatible asm syntax and encouraging tools not to
> > support the old syntax (and particularly, not to support generating
> > thumb2 from it, despite the fact that there's no fundamental reason it
> > couldn't be done).
> > 
> > BTW for other things I think we need some sort of syntax directive to
> > tell the assembler we'll be using the unified syntax -- is this right?
> > Do you know what the minimum gas version that supports this directive
> > is?
> 
> ..syntax unified (binutils supports it since 2005).

Hm? That would include 2.17. So is the new vfp syntax separate from
UAL-vs-legacy?

> and the default is divided syntax
> (so inline asm has to use divided syntax or
> ".sytax unified"
> ....
> ".syntax divided")

Uhg, and it's the opposite for clang with integrated assembler, right?
Thankfully most instructions you'd actually use look the same either
way...

Rich

Re: status of armhf asm with VFP instructions

[Rich Felker]

On Thu, Oct 15, 2015 at 09:03:46PM -0400, Rich Felker wrote:
> On Fri, Oct 16, 2015 at 02:33:13AM +0200, Szabolcs Nagy wrote:
> > * Rich Felker <dalias@libc.org> [2015-10-15 20:00:56 -0400]:
> > > On Fri, Oct 16, 2015 at 01:16:07AM +0200, Szabolcs Nagy wrote:
> > > > most likely ual is the long term solution.
> > > > 
> > > > maybe it is best to switch to ual and then write that script
> > > > if ppl with old binutils run into issues.
> > > 
> > > That sounds like it might be the best option. I don't like dropping
> > > support for old stuff, but ARM really made a mess of this by making a
> > > new gratuitously incompatible asm syntax and encouraging tools not to
> > > support the old syntax (and particularly, not to support generating
> > > thumb2 from it, despite the fact that there's no fundamental reason it
> > > couldn't be done).
> > > 
> > > BTW for other things I think we need some sort of syntax directive to
> > > tell the assembler we'll be using the unified syntax -- is this right?
> > > Do you know what the minimum gas version that supports this directive
> > > is?
> > 
> > ..syntax unified (binutils supports it since 2005).
> 
> Hm? That would include 2.17. So is the new vfp syntax separate from
> UAL-vs-legacy?

I just tested and gas 2.17 accepts the new syntax for vabs and vsqrt
if you use .syntax unified (they're errors without the directive). But
the vmsr/vmrs are still rejected. :(

However it seems like we can safely convert all the other existing asm
to UAL and have it work with all relevant binutils versions at least
as well as it's working now. In particular this should allow fixing
the mess in memcpy, etc.

The arm atomics file is still a mess of non-thumb-compatible code (it
actually does arithmetic on pc that depends on arm opcode size) but I
want to replace it anyway now that the new dynamic linker init
sequence does not need atomics that work before the thread pointer is
initialized. So I think we're in good shape for transitioning towards
Cortex-M support.

Rich

Re: status of armhf asm with VFP instructions

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 3442 bytes --]


> On Oct 15, 2015, at 4:16 PM, Szabolcs Nagy <nsz@port70.net> wrote:
> 
> * Rich Felker <dalias@libc.org> [2015-10-15 18:44:25 -0400]:
>> On Fri, Oct 16, 2015 at 12:33:20AM +0200, Szabolcs Nagy wrote:
>>> it is not possible to write arm asm in a way that pleases all
>>> assemblers, here is a summary of the problems relevant to musl:
>>> 
>>> some instructions can be written in several ways since UAL
>>> (= unified assembler language) was introduced to unify arm
>>> and thumb instruction mnemonics.
>>> 
>>> in case of armhf VFP instructions musl uses the following ones
>>> in hand written asm:
>>> 
>>> hex       ual         old
>>> 
>>> eeb1XacX  vsqrt.f32   fsqrts
>>> eeb1XbcX  vsqrt.f64   fsqrtd
>>> eeb0XacX  vabs.f64    fabss
>>> eeb0XbcX  vabs.f64    fabsd
>>> eef1Xa10  vmrs fpscr  mrc p10,7,..
>>> eee1Xa10  vmsr fpscr  mcr p10,7,..
> 
> sorry, for reading/writing fpscr fmrx/fmxr can be used in the
> old syntax instead of vmrs/vmsr, but clang does not know
> those names.
> 
>>> the issues:
>>> 
>>> (1) binutils gas rejects UAL VFP instructions unless either
>>> the -mfpu=<vfp variant> option is passed or the asm source
>>> has '.fpu <vfp variant>' directive, the old names work though
>>> (if the target is hard float).  A gcc toolchain built
>>> --with-float=hard but without --with-fpu=<vfp variant> does not
>>> pass -mfpu to the assembler.
>>> 
>>> (2) Most UAL mnemonics were added in binutils 2.18, older
>>> binutils only supports the old syntax.  Some UAL mnemonics were
>>> added later, vmrs and vmsr only appear in binutils 2.21
>>> (released in 2010).
>>> 
>>> (3) The clang assembler does not support old mnemonics in general
>>> but includes a few exceptions (e.g. fabs and fsqrt are supported,
>>> but not the mrc or mcr coprocessor instructions).
>>> 
>>> Using UAL asm is the clean solution, but then to fix (1) we
>>> should have .fpu directives in the asm files.
>>> 
>>> However the conflict between (2) and (3) means that fenv code
>>> using vmrs and vmsr either drops support for old binutils gas
>>> or the clang assembler.
>> 
>> It seems we're already using the new forms vsqrt and vabs in
>> src/math/armhf/*.s. So using vmrs/vmsr presumably will not break
>> support for any toolchains that work now.
>> 
> 
> vmrs/vmsr can break on old binutils versions (2.18 - 2.20) and
> 2.20 is not that ancient.. is that ok?
> 
>> I think the reason this went unnoticed for so long is that Aboriginal
>> Linux (the only real user of the ancient binutils, due to GPL v2 vs v3
>> issues) does not use the armhf ABI at all; it only targets standard
>> EABI for which musl does not use any math/fenv asm.
>> 
>> So I'm ok with the fpu-related changes proposed, but I'm not sure what
>> to do about UAL issues elsewhere. Right now we have a lot of files
>> with instructions written as .word in them which is a mess and which
>> precludes Cortex-M (thumb2-only) targets. These are files which need
>> to be built even on non-hf, so changing them presumably will break
>> support for old binutils. As a workaround, users needing old binutils
>> could perhaps misuse the ASM_CMD var in the Makefile to run a sed
>> script that replaces UAL with old-syntax asm. Or someone could patch
>> the old binutils to accept UAL...
>> 
> 
> most likely ual is the long term solution.

thats right.

> 
> maybe it is best to switch to ual and then write that script
> if ppl with old binutils run into issues.

agree here.


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 204 bytes --]

Re: status of armhf asm with VFP instructions

[Rich Felker]

On Fri, Oct 16, 2015 at 01:58:09AM +0200, Szabolcs Nagy wrote:
> * Szabolcs Nagy <nsz@port70.net> [2015-10-16 01:16:07 +0200]:
> > * Rich Felker <dalias@libc.org> [2015-10-15 18:44:25 -0400]:
> > > It seems we're already using the new forms vsqrt and vabs in
> > > src/math/armhf/*.s. So using vmrs/vmsr presumably will not break
> > > support for any toolchains that work now.
> > > 
> > 
> > vmrs/vmsr can break on old binutils versions (2.18 - 2.20) and
> > 2.20 is not that ancient.. is that ok?
> > 
> 
> attached the old armhf patch with updated commit message.

> >From 542d4003a60320ac0446b156681c59cbc19dd6a1 Mon Sep 17 00:00:00 2001
> From: Szabolcs Nagy <nsz@port70.net>
> Date: Tue, 21 Jul 2015 20:00:03 +0000
> Subject: [PATCH] fix armhf asm to use .fpu vfp and UAL mnemonics
> 
> (1) Some armhf gcc toolchains (built with --with-float=hard but without
> --with-fpu=vfp*) do not pass -mfpu=vfp to the assembler and then binutils
> rejects the UAL mnemonics for VFP unless there is an .fpu vfp directive
> in the asm source.

I've committed just this part 1 since it's independent of the other
changes and should yield nothing but an improvement in compatibility.
I'd still like to go ahead with all the UAL changes after release.

Rich