This is the mail archive of the
mailing list for the binutils project.
Re: GAS .fpu directive
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Renato Golin <renato dot golin at linaro dot org>, Matt Thomas <matt at 3am-software dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Wed, 27 Aug 2014 17:41:23 +0100
- 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> <6D39441BF12EF246A7ABCE6654B0235320EF47F9 at LEMAIL01 dot le dot imgtec dot org> <B2E0E3AA-8421-4504-B1B9-3305AD6D394F at 3am-software dot com> <CAMSE1kegoq6Upp4auoEKcLnVTJH-z1bajj19s_0K=TxBTqdo0Q at mail dot gmail dot com>
On 27/08/14 17:23, Renato Golin wrote:
> On 27 August 2014 01:56, Matt Thomas <email@example.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
>> 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.
>> 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.