GAS .fpu directive

[Richard Earnshaw]

On 27/08/14 17:23, Renato Golin wrote:
> On 27 August 2014 01:56, Matt Thomas <matt@3am-software.com> wrote:
>> You could have something
>>
>> .fpu neon
>> <function neon>
>>
>> .fpu vfp2
>> <function vfp2>
> 
> There is no way of poping context, so the .fpu vfp2 would be valid for
> the rest of the file unless you knew what the previous flag was and
> added at the end of your sub-context. This is not always possible with
> inline asm, or included asm, or even if the compiler is implementing
> IFUNC.
> 
> 
>> and then the caller decides what routine to call depending on the presence
>> of neon or not (GNU IFUNC per chance).  Same could be said for pre-r6 mips
>> code and mipsr6 mips code.  Forcing them to be separate files seems harsh.
> 
> Between harsh and incorrect, I choose harsh any day.
> 

It depends on whether "incorrect" here means "if you don't know what
you're doing you can foul things up; but if you're careful, this is very
powerful", or whether it means, "this is fundamentally broken".

I think someone needs to go away, think about *all* the use cases that
are needed; ponder through how those map on to the assembler directives
and attribute scheme we have (not forgetting that gas/binutils don't use
all of the section/function based attribute features), and comes up with
a way of supporting what's needed.  If that can be done by adjusting the
current scheme, without breaking existing code, then great.  If it means
a migration plan towards a new set of directives, then that's
unfortunate, but at least we should be moving towards something that has
a potential long-term future (we could then leave the existing
directives in place, but deprecate them and gradually migrate over to a
new set that we clearly document).

What I don't want to see is someone tinkering with what is clearly a
fragile API and causing problems for existing toolchains without having
worked through the issues.

I might be able to do some of that thinking, but it's not going to be in
the next few weeks.  Sorry, other things have higher priority.

R.

> 
>> I would except the attributes emitted to first match the -mfpu=xxx
>> option passed to gas, then the first .fpu directive encountered.
> 
> I think we all agree on this one, except when the first .fpu flag is
> actually from an overriding snippet, say, an IFUNC implementation,
> where you *don't* want that to be the default.
> 
> 
>> Forcing them to be in the "header" makes cpp-processed assembly
>> more painful than it should be.
> 
> The reason why I suggest that is outlined above. Again, better harsh
> than incorrect.
> 
> cheers,
> --renato
>