This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC 2.0] Implementing hwcap2
- From: Roland McGrath <roland at hack dot frob dot com>
- To: David Miller <davem at davemloft dot net>
- Cc: rsa at us dot ibm dot com, libc-alpha at sourceware dot org
- Date: Mon, 8 Apr 2013 16:29:52 -0700 (PDT)
- Subject: Re: [RFC 2.0] Implementing hwcap2
- References: <20130408220507 dot 5699D2C088 at topped-with-meat dot com> <20130408 dot 181229 dot 1335787366109649538 dot davem at davemloft dot net> <20130408223743 dot 7FA9E2C088 at topped-with-meat dot com> <20130408 dot 185933 dot 1477627444584685494 dot davem at davemloft dot net>
> 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