RE: Merge MIPS libc-abis into top-level

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Wed, 22 Oct 2014, Matthew Fortune wrote:

> 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.

Anything involing getting approval from each architecture maintainer seems 
like something to be avoided if possible as causing long bottlenecks 
(months) on changes.

If you don't do the timestamp-based merging, then the implication is that 
any new architecture-independent abiversion needs adding to files for each 
architecture with some architecture-specific abiversion - but I don't see 
any point in duplicating copies of the file with no architecture-specific 
abiversions.  That is, my suggestion (if we don't do timestamp-based 
merging) would be:

* Each architecture with IFUNC support gets a copy of the file, mentioning 
both UNIQUE and IFUNC, but with abbreviated comments like in the MIPS file 
rather than the full ones present in the top-level file.

* The top-level file only has UNIQUE.

* Once that is done, the PLATFORM column should be removed from the files 
and all code processing it removed (so that exactly one such file is found 
through sysdeps, and that file always processed).

* Add files mentioning both UNIQUE and IFUNC for S/390, AArch64 and ARM.

* Anyone adding new architecture-independent features to binutils in 
future that require abiversion settings because of incompatibility with 
older dynamic linkers has the responsibility to ensure the value depends 
correctly on the architecture.

-- 
Joseph S. Myers
joseph@codesourcery.com