RE: Merge MIPS libc-abis into top-level

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

Joseph S. Myers <joseph@codesourcery.com> writes:
> On Wed, 1 Oct 2014, Matthew Fortune wrote:
> 
> > This patch merges the MIPS specific libc-abis file into the top
> > level. MIPS is the only port with a custom file while there are
> > several conditional entries in the top level file already. I
> > suspect the only reason we have the custom file is because of
> > MIPS coming from the ports tree. Now that ports are gone this
> > is no longer an issue.
> 
> But the direction we are following is that the way ports architectures did
> things is generally the preferred direction and non-ex-ports architectures
> should follow it - that is, avoid anything architecture-specific in
> architecture-independent files, with sysdeps directories used for all
> selection of anything architecture-specific.  So it would seem better to

OK. I wasn't really doing anything more conscious than trying to fit in with
all the other archs. I have read all the libc-abis threads but nothing
really suggests a need for some clever handling of them. They just aren't
used enough to warrant much development.

> work out a design that moves architecture-specific content out of the
> toplevel file, and eliminates the special-case matching against
> $(base-machine)-$(config-vendor)-$(config-os) with normal sysdeps
> searching being used instead, while still avoiding duplication between
> architectures as much as possible.

I can envisage a way of achieving that but I'm not particularly
convinced that there is anything architecture independent about ABI
versions. The names may be common but numbering is clearly not and
like any other ELF definitions they should be explicit in my opinion.

A proposal to have multiple sources of features which lead to increased
ABIVERSIONs would be to list a datestamp next to each feature. Merging
all the features together and ordering for any given architecture will
give the correct numbering. All existing features would need dates
inventing to give correct the initial order.

The top level libc-abis would therefore just list:

<timestamp> UNIQUE

And each arch would just list the arch dependent features; MIPS:

<timestamp> MIPS_PLT
<timestamp> MIPS_O32_FP64

and any addons would do the same. (I'm ignoring the case where an addon may
not be arch independent as that would seem weird). All these libc-abis are
merged, sorted and processed. The only quirk is that the addon libc-abis
must always be processed regardless of whether they are enabled or not
otherwise the numbering would be wrong.

Although that is a rough outline of how we could continue to have arch
independent libc-abis as well as arch dependent, I don't think it is a
good idea to split them. If the OSABI and 'arch-ABI' had an independent
version number then it would obviously make sense but they don't or at
least ABIVERSION has already been used to version both of these things.

>From an arch perspective I don't think it is acceptable for anyone to
introduce a new libc-abi that claims to be arch-independent without
explicitly getting approval from every arch maintainer as a new value
will be required. It seems appropriate to have to update a file in
each sysdeps folder to get that approval. With that in mind I suggest
copying the libc-abis to every arch folder and removing the top level
file.

Thanks,
Matthew