[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151016000056.GB8645@brightrain.aerifal.cx>
Date: Thu, 15 Oct 2015 20:00:56 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: status of armhf asm with VFP instructions
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
