Re: [RFC 2.0] Implementing hwcap2

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

> I do not think this argument holds.

You are mistaken, but not because the points you make aren't right,
only because they are subsumed in what I said.

> If we, for example, add IFUNC support for sparc on libgmp, a user
> would be reasonable to try and build libgmp on an existing system with
> an existing libc and expect it to work.

Agreed.

> He also would be reasonable to expect that libgmp to continue working
> after upgrading glibc.

Agreed.

> So, we can't change the interface even if there are no existing users,
> because there are going to be future users of the interface we have
> now and there is no way to prevent that.

I posit that the interface is sufficiently obscure, and still sufficiently
young, that it may well be practical to prevent any such actual uses.

For the example of libgmp on sparc, libgmp's configure check for IFUNC
support could be made to admit only the newfangled support and not the
oldfangled support.

> If they are built targetting the current libc IFUNC interface, they
> will break when we change the calling convention.  

The supposition is that nothing is or would be built to target the current
("oldfangled") IFUNC interface.

> If they are built against a changed IFUNC calling convention, they will
> break when deployed on systems with current libc.

This takes more creativity to prevent.  That is, to prevent it being a
subtle and confusing break rather than the straightforward break that
would result from building libgmp against a new libc such that it
requires a new symbol version set that current libc doesn't define.
In the general case, building a binary against a newer libc must always
be presumed to break when deployed on systems with an older libc.

> The issue is that the API exists on the ELF level rather than that
> of a traditional C interface.

Indeed.  We have dealt with other such cases more or less adequately
(DT_GNU_HASH, STB_GNU_UNIQUE, etc.).  But even those were not as
graceful as one would have liked (except perhaps for --hash-style=both,
which is pretty thoroughly fine).  And none of those past cases involved
an ELF ABI element that had an old-version-ABI to new-version-ABI
transition rather than the simpler introduction of a wholly new ABI
element.  That's essentially why I am inclined toward the position that
STT_GNU_IFUNC is still not really ready for prime time.

> I still maintain that we can't change the calling convention.

I still maintain that this decision is yours for sparc and belongs
to others for other machines.


Thanks,
Roland