Re: GAS .fpu directive

[Renato Golin <renato dot golin at linaro dot org>]

On 26 August 2014 10:13, Will Newton <will.newton@linaro.org> 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
already use:

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.

cheers,
--renato