Re: status of armhf asm with VFP instructions

[Rich Felker <dalias@libc.org>]

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