This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: GAS .fpu directive

Renato Golin <> writes:
> On 21 August 2014 08:32, Matthew Fortune <>
> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]