This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC 2.0] Implementing hwcap2
- From: David Miller <davem at davemloft dot net>
- To: roland at hack dot frob dot com
- Cc: rsa at us dot ibm dot com, libc-alpha at sourceware dot org
- Date: Mon, 08 Apr 2013 18:59:33 -0400 (EDT)
- 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>
From: Roland McGrath <roland@hack.frob.com>
Date: Mon, 8 Apr 2013 15:37:43 -0700 (PDT)
>> The existing calling convention has several glibc releases worth of
>> exposure, plus it's the one in use on all Linux distributions.
>>
>> I frankly don't think we can safely change it for any target, and at
>> the same time expect any level of adoption outside of glibc
>> whatsoever.
>
> The notion that it might be acceptable to make an incompatible change is
> predicated on the supposition that IFUNC resolver arguments are not used
> anywhere outside libc itself today and that other things using them for
> the machine in question won't happen (or might as well be delayed) until
> a new libc release is made and deployed to places where people might
> build such other things. I maintain that the truth of this supposition
> differs by machine. It's up to you to say how it is for sparc.
I do not think this argument holds.
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.
He also would be reasonable to expect that libgmp to continue working
after upgrading glibc.
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.
If they are built targetting the current libc IFUNC interface, they
will break when we change the calling convention. If they are built
against a changed IFUNC calling convention, they will break when
deployed on systems with current libc.
> We have hitherto been fairly cavalier about the introduction of the
> feature. But I think its nature dictates that we take a much more
> deliberate approach. In particular, there is no plausible means I can
> think of by which we can version this interface like we do normal
> function interfaces.
The issue is that the API exists on the ELF level rather than that
of a traditional C interface.
I still maintain that we can't change the calling convention.