[RFC] Remove platform dependent information from top-level libc-abis

[RFC] Remove platform dependent information from top-level libc-abis

[Matthew Fortune]

As the MIPS port is making changes to the libc-abis file it seems
appropriate for me to address the various comments which have been made
about how libc-abis works.

My perspective is that libc-abis is inherently an arch specific
concept. I.e. One arch may have more special features than another. This
means that the features listed in libc-abis may get different numbers
assigned.

The rules (constructed via discussion with Joseph) 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.
i.e. Add files mentioning both UNIQUE and IFUNC for S/390, AArch64 and ARM.

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

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

Any objections? If not I will send patches for all affected architectures

Libc-abis threads:

https://sourceware.org/ml/libc-alpha/2014-10/msg00018.html
https://sourceware.org/ml/libc-alpha/2014-01/msg00375.html

thanks,
Matthew

RE: [RFC] Remove platform dependent information from top-level libc-abis

[Matthew Fortune]

Matthew Fortune <matthew.fortune@imgtec.com> writes:
> As the MIPS port is making changes to the libc-abis file it seems
> appropriate for me to address the various comments which have been made
> about how libc-abis works.
> 
> My perspective is that libc-abis is inherently an arch specific concept.
> I.e. One arch may have more special features than another. This means
> that the features listed in libc-abis may get different numbers assigned.
> 
> The rules (constructed via discussion with Joseph) 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.
> i.e. Add files mentioning both UNIQUE and IFUNC for S/390, AArch64 and
> ARM.
> 
> * 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).
> 
> * 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.
> 
> Any objections? If not I will send patches for all affected architectures
> 
> Libc-abis threads:
> 
> https://sourceware.org/ml/libc-alpha/2014-10/msg00018.html
> https://sourceware.org/ml/libc-alpha/2014-01/msg00375.html

Ping, any interest in this topic? If nobody really cares I'll post a patch
to do the above and see what happens from there.

Matthew

RE: [RFC] Remove platform dependent information from top-level libc-abis

[Roland McGrath]

I think it does make sense to consider these values as machine-dependent.
However, I also want to make sure that we do something to prevent the
danger of new machine-independent features being added but some machines
with their own libc-abis files failing to update.

RE: [RFC] Remove platform dependent information from top-level libc-abis

[Matthew Fortune]

> I think it does make sense to consider these values as machine-dependent.
> However, I also want to make sure that we do something to prevent the
> danger of new machine-independent features being added but some machines
> with their own libc-abis files failing to update.

I'm not sure that there is any real danger in machine dependent libc-abis
not being updated and there may be a justifiable reason why some ports
adopt the feature after others. I.e. if binutils also grows a framework
for generic ABIVERSIONs vs machine dependent then it is reasonable that
the generic version would get updated first and each arch (that has taken
control of its ABIVERSIONs) can then update at their discretion.

I was thinking that a carefully phrased comment in the top level libc-abis
would be sufficient to make people consider the arch specific libc-abis.

A more complex solution would require checking that all values in the top
level libc-abi are present in the sysdeps libc-abi (or perhaps recorded as
explicitly not yet supported). The problem here is that you have to build
every port to run the check so it may not add much value.

Matthew

RE: [RFC] Remove platform dependent information from top-level libc-abis

[Roland McGrath]

> I'm not sure that there is any real danger in machine dependent libc-abis
> not being updated and there may be a justifiable reason why some ports
> adopt the feature after others. I.e. if binutils also grows a framework
> for generic ABIVERSIONs vs machine dependent then it is reasonable that
> the generic version would get updated first and each arch (that has taken
> control of its ABIVERSIONs) can then update at their discretion.

The scenario that concerns me is a generic new feature being added to
binutils and to machine-independent libc code, while some libc machine
maintainers fail to notice entirely.  (Sometimes the machine maintainer is
the same person for binutils and libc or they are in close collaboration,
but not always.)

> I was thinking that a carefully phrased comment in the top level libc-abis
> would be sufficient to make people consider the arch specific libc-abis.

People ignore comments.  Reviewers fail to notice relevant past comments.
Actual red flags that cannot easily be overlooked are much better.

> A more complex solution would require checking that all values in the top
> level libc-abi are present in the sysdeps libc-abi (or perhaps recorded as
> explicitly not yet supported). The problem here is that you have to build
> every port to run the check so it may not add much value.

That's the sort of thing I had in mind.  It's fine if the problem on a
given machine isn't noticed until someone builds for that machine.  It adds
just as much value as every other test we have.  Machine maintainers run
all the tests before we make a release, so they will notice the failure then.