This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: GAS .fpu directive
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Renato Golin <renato dot golin at linaro dot org>
- Cc: Peter Bergner <bergner at vnet dot ibm dot com>, Richard Earnshaw <rearnsha at arm dot com>, Nicholas Clifton <nickc at redhat dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Thu, 21 Aug 2014 09:02:06 +0000
- Subject: RE: GAS .fpu directive
- Authentication-results: sourceware.org; auth=none
- References: <CAMSE1keWd0+uUS0fpaC3-yXsnN-z2_Bsa5anwvQAQwXgWuw_Yw at mail dot gmail dot com> <53F4C261 dot 8090900 at redhat dot com> <53F4CB31 dot 9080701 at arm dot com> <1408553484 dot 5894 dot 8 dot camel at otta> <CAMSE1kdDQOuuKhPcF8qasM-PMXBkAKDfjioCmYc39cORV3o4gA at mail dot gmail dot com> <1408562067 dot 5894 dot 23 dot camel at otta> <CAMSE1kfq3CoxR8KWOo6dzgoR4CxyLqyA+_o=ZVU_MfJwHf8-mA at mail dot gmail dot com> <6D39441BF12EF246A7ABCE6654B0235320EF4632 at LEMAIL01 dot le dot imgtec dot org> <CAMSE1kdvh+uVriMQV1LeJJYGVY-g7BcO0ZVsESiGUeXs132eBw at mail dot gmail dot com>
Renato Golin <renato.golin@linaro.org> writes:
> On 21 August 2014 08:32, Matthew Fortune <Matthew.Fortune@imgtec.com>
> wrote:
> > I guess the question for ARM is whether the .fpu directive changes the
> > annotation on the object file and if it does, does it do it every time
> it
> > is seen or just the first time. If it changes the overall module each
> time
> > then that sounds like a source of weird and had-to-find problems.
>
> As far as I understand, .fpu and .cpu are GNU extensions that end up
> setting the build attributes in the final object file, which in turn
> lets the linker knows what kind of libraries it should link against.
> This is not like IFUNC, but it's more of a "give the the most
> optimized libraries you have for my particular target" and also "don't
> let me shoot my own foot and accidentally compile different object
> files with the wrong flags".
>
> So, in both these cases, GAS sets FP_arch = VFPv2:
>
> .fpu vfpv2
> vabs.f32 s1, s0
> .fpu vfp
> faddd d1, d0, d0
>
> .fpu vfp
> faddd d1, d0, d0
> .fpu vfpv2
> vabs.f32 s1, s0
>
> In that first case above, LLVM is even worse and sets the last before
> even parsing vabs, so it fails with "vabs requires vfp2".
>
> I don't know what the best behaviour is, but if I had to guess, I'd
> say either the first (which is more likely to be in the file header)
> or the most general (for ex. vfpv3 trumps vfp, but that has corner
> cases), or the one that we specifically detected to be in the header
> (before any instruction), if any.
FWIW given that behaviour my suggestion would be that for .fpu you would
want to enforce just one .fpu directive and that should precede all code.
I guess that might break some existing code though but I'd say that is a
good thing.
Introducing a new directive to select the 'current' fpu may then be
necessary for some use cases though. The current situation doesn't sound
good from a hand-coded assembler nor compiler perspective. It seems fairly
undesirable to allow an inline asm block to affect a module's attributes.
It seems less likely to occur in hand-written assembler but the results
would be equally confusing if multiple .fpu directives did appear.
Regards,
Matthew