This is the mail archive of the
mailing list for the binutils project.
Re: GAS .fpu directive
- From: Renato Golin <renato dot golin at linaro dot org>
- To: Will Newton <will dot newton at linaro dot org>
- Cc: Matthew Fortune <Matthew dot Fortune at imgtec dot com>, 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: Tue, 26 Aug 2014 10:45:48 +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> <CAMSE1kfrQ5+tKZBywh6dx9VdXhrMosDdwsJUZV6LZm9oY6Mbqg at mail dot gmail dot com> <CAMSE1kfpVWgo_8qy6Fgi6J2f4Bg_w7ricD27gPgjr0+aCL6fkw at mail dot gmail dot com> <CANu=Dmi+t5Khp3U+p=ttZ0EubzYAfiD+NWkAtrRdhTvFGBKonA at mail dot gmail dot com>
On 26 August 2014 10:13, Will Newton <email@example.com> wrote:
>> $ echo ".cpu cortex-a8" | as -mcpu=arm11
>> should produce ARM11 as CPU type.
> This is the opposite of what currently happens so I suspect may be a
> non-starter from a compatibility standpoint.
I'm ok with the flags overriding the command line, if that's the
current understanding, but there must be a clear winner. If that's the
flag, so be it.
> Patches are welcome, but it would be good to be clear on what the
> advantages of each individual change are as it is possible people are
> relying on various quirks to build their code. I admit the current
> status quo doesn't make a whole lot of sense, but I am also reluctant
> to make gas into a stick to beat Chromium developers with. ;-)
I understand that GNU tools are generally a lot more forgiving than
LLVM based ones, but there are some things that don't make sense.
This is not the first example that we found where GNU tools are not
clear on what the implementation had to be in the first place, which
allowed developers to rely on nonsensical behaviour. But after a whole
year interacting with those communities (kernel, android, chromium),
there were only a very limited number of times (<1%) where the code
was correct (in all senses). Most of the time it was the wrong
solution in the wrong place, abusing of a broken behaviour from tools
because "it just worked".
Nowadays, whenever someone opens a bug with the text "Clang fails to
support X, like GCC/GAS/LD", I tend to assume the code is wrong, that
the tool mentioned is lax and that the developer is lazy enough to not
check the standards. Which ends up most invariantly true.
Now, there are some reasons to fix existing lax behaviour that people
1. Maintenance. Can anyone know every possible use of every possible
badly defined behaviour in every possible software out there? Are you
ready to support any two (or more) incompatible relaxed behaviour
across all of GNU tools? Are you actually going to create test cases
to make sure that these unknown uses of your undefined feature is
actually correct? Are you going to document that as the "expected"
behaviour and maintain it as a feature? Isn't the compiler allowed to
change its own undefined behaviour for better code generation?
2. Correctness. This functionality is not just undefined, but it
produces invalid objects and it goes against common sense. If I have
an .fpu on the header and I happen to include another asm file or
inline asm or someone add a .fpu below, it will change the global
state of that object. This will cause all sorts of failures from
(hopefully) compilation time all the way to dynamically linking or
execution. Toolchains should warn about all possible errors that the
user might see, if they can. We can, in this case.
3. Education. This is not just a stick to beat Chromium developers
with, it's a way to make toolchain development sane, too. GCC's errors
and warnings are improving a lot recently, and Clang's diagnosis have
always been great, and my take on this is that we don't want to keep
receiving horrendous bug reports of things that shouldn't even
compile. There are limits and the users will *never* set them, we
must. That's why there are ABIs, standards, committees and user
groups, to define what's sane and what's not and to educate developers
on how to best write their software.
We all know how developers (including myself) have the mentality that
"correct C code" == "gcc compiles", so if the compiler doesn't
complain, it *must* be correct. It then follows that toolchains are,
indeed, educational tools, and it is our responsibility to make sure
it's a good one. For *our* own sake.