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

[Roland McGrath <roland at hack dot frob dot com>]

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