Re: [RFC] ARM Floating point defaults

[Richard Earnshaw <rearnsha at gcc dot gnu dot org>]

> I think that we ought to make it a principle that GCC (for ARM) always 
> tells GAS explicitly what ISA and ABI it has used to produce its 
> assembler output, so that whatever defaults are built in to GAS are ignored.
> 

Yep, and I think I implied (if I didn't explicitly say) exactly the same
thing in my previous mail.

> > So one option would be to just remove the checking entirely until we can
> > come up with a more robust solution -- it's then caveat emptor for those
> > developing with GCC, but that's probably less of a nightmare than having
> > legitimate objects that the linker spuriously rejects (most real users
> > of GCC only have one type of target at any one time).
> 
> I would actually agree with this.  The tests and warnings about floating 
> point mismatches have caused quite a few bug reports, and to my 
> knowledge have not proved to be that useful at all.
> 

So I think we probably have consensus here.  That's good.

> I am however concerned that we do not have a proper scheme for labelling 
> object files so that these warnings could be correctly generated.  So I 
> would be much happier if instead of just deleteing these checks we could 
> come up with a replacement for them and start implementing it.

Indeed.  However, getting this right is hard...  Many of the existing
problems stem from the fact that the previous design was wrong at a
fundamental level.  That was partly because the number of possible
variants was smaller when the scheme was first devised, so its
weaknesses were less apparent.

What we need is at least 3-way and possibly 4-way attributes for some of
this (simple binary, or 2-way, attributes is where the existing scheme
really falls down).

So in many cases we need to know if:
a) The feature is used
b) The feature is explicitly NOT used
c) A module is independent of the feature (compatible with both)
d) The feature's use is not unknown

In many cases d) can be treated in the same way as c), but there are
subtle differences.  For c) we know the result will be correct, but for
d) we have to assume the user knows what they are doing.  In practice we
can always record d) by not mentioning the feature at all.

When it comes to using the attributes it isn't a simple 'is this object
feature-compatible with that objects'.  It may be a single feature's
compatibility is only important if some other attribute is asserted (for
example, ARM/Thumb interworking is only a significant issue if the code
is not architecture v5.

Now it's clear we can't accurately derive the first three attributes
from the command line options (there's no command-line option that gcc
can generate based on the result of compiling the code) so we need an
alternative method for specifying the attributes than simple command
line flags.

We also need a more powerful way of recording this information in the
object file.  A simple bit-set in the header is highly toolchain
specific and we need a way of knowing when we are dealing with objects
produced by other toolchains (irrespective of whether we can understand
whether or not they use the same feature description mechanism).

So how do we specify the attributes to the assembler?  My suggestion
(based in part on what ARM's tools do) is to have a directive in the
body of the assembly file that can assert a single feature -- I really
don't think the assembler should care what the asserted feature is, it
should just record the information in the object file.  That implies
that the features should be left as strings, but still leaves open the
issue of where they should be recorded (magic symbols, special sections,
etc).  The syntax should probably be something like

	.feature	<feat>	<value>

which opens up the possibility to record things like:

	.feature	architecture	v5

Depending on how we wish to record this information there may be
constraints on the values (eg no use of white space, or some other
characters).

As for how we record all this I'm less certain.  Using special sections
is one option, but that rather implies a smart(ish) linker that can
merge the sections correctly (it's not necessarily the union of the two
sets of attributes) or it means very careful construction of the
attributes so that they can be merged by union; or it means creating a
structure in the section that means that a suitably intelligent linker
can understand what partial linking has already been done.