Merge MIPS libc-abis into top-level

This is a precursor to MIPS ABI work which was originally posted:

https://sourceware.org/ml/libc-alpha/2014-05/msg00332.html

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.

The reason this is part of the overall MIPS ABI work is that a
new value will be added and it seemed like an appropriate time
to get rid of the file.

Tested with no regression for mips-linux-gnu.

OK to commit? If so can I (user:mpf) request commit access to
glibc.

Thanks,
Matthew

	* libc-abis: Add MIPS_PLT prior to UNIQUE.
	* sysdeps/unix/sysv/linux/mips/libc-abis: Remove.
---
 libc-abis                              |  3 +++
 sysdeps/unix/sysv/linux/mips/libc-abis | 13 -------------
 2 files changed, 3 insertions(+), 13 deletions(-)
 delete mode 100644 sysdeps/unix/sysv/linux/mips/libc-abis

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

See also the discussion in 
<https://sourceware.org/ml/libc-alpha/2014-01/msg00375.html> and the 
references therefrom.  I think a more careful analysis of libc-abis issues 
would be needed to justify any particular patch merging or splitting 
files.

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

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

I generally agree but in this case not getting approval for an ABI increase
seems wrong.

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

I think your suggestion is sufficient to cover the likely needs of
libc-abis. Since this only affects the glibc build system and internals
then it can always be made more elaborate when faced with some complex
scenario.

Unless you have an objection I'm happy to re-post your suggestion on a new
thread to get consensus.

Matthew

On Tue, 28 Oct 2014, Matthew Fortune wrote:

> I think your suggestion is sufficient to cover the likely needs of
> libc-abis. Since this only affects the glibc build system and internals
> then it can always be made more elaborate when faced with some complex
> scenario.
> 
> Unless you have an objection I'm happy to re-post your suggestion on a new
> thread to get consensus.

I do not have an objection.