Message ID | 6453f4f9-75b5-68b9-0e6b-22f40aaee599@redhat.com |
---|---|
State | Dropped |
Headers |
Received: (qmail 25087 invoked by alias); 13 Apr 2017 13:09:59 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 25071 invoked by uid 89); 13 Apr 2017 13:09:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=nf X-HELO: mx1.redhat.com DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3575AC04BD3C Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 3575AC04BD3C To: GNU C Library <libc-alpha@sourceware.org> From: Florian Weimer <fweimer@redhat.com> Subject: Compat symbols in abilist files Message-ID: <6453f4f9-75b5-68b9-0e6b-22f40aaee599@redhat.com> Date: Thu, 13 Apr 2017 15:09:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------ACDD9B1D7FDD909EC178C222" |
Commit Message
Florian Weimer
April 13, 2017, 1:09 p.m. UTC
I've come up with the attached patch to mark compat symbols as such in the abilist files. Do we want to do this? The downside is that when building glibc in certain non-standard configurations, some symbols are not compat symbols anymore (the prime example is probably --enable-obsolete-rpc). On the other hand, the additional verification is valuable. Thanks, Florian
Comments
On Apr 13 2017, Florian Weimer <fweimer@redhat.com> wrote: > Do we want to do this? The downside is that when building glibc in > certain non-standard configurations, some symbols are not compat symbols > anymore (the prime example is probably --enable-obsolete-rpc). Does that mean check-abi fails in that case? Andreas.
On 04/13/2017 03:16 PM, Andreas Schwab wrote: > On Apr 13 2017, Florian Weimer <fweimer@redhat.com> wrote: > >> Do we want to do this? The downside is that when building glibc in >> certain non-standard configurations, some symbols are not compat symbols >> anymore (the prime example is probably --enable-obsolete-rpc). > > Does that mean check-abi fails in that case? Yes, it would. Thanks, Florian
On Thu, 13 Apr 2017, Florian Weimer wrote: > I've come up with the attached patch to mark compat symbols as such in the > abilist files. > > Do we want to do this? The downside is that when building glibc in certain > non-standard configurations, some symbols are not compat symbols anymore (the > prime example is probably --enable-obsolete-rpc). On the other hand, the > additional verification is valuable. I'd consider whether a symbol is a compat symbol to be part of the API, not the ABI; I don't think it belongs in these files. It may well make sense to be able to assert that a particular symbol is not available for new programs to link against, for either static or dynamic linking. Or that any given symbol has at most one non-compat version, in at most one library, except for cases (if any) explicitly whitelisted as deliberately having public versions in more than one library.
On 04/13/2017 09:09 AM, Florian Weimer wrote: > I've come up with the attached patch to mark compat symbols as such in the abilist files. > > Do we want to do this? The downside is that when building glibc in certain non-standard configurations, some symbols are not compat symbols anymore (the prime example is probably --enable-obsolete-rpc). On the other hand, the additional verification is valuable. I think this is a good idea. We should detect changes in compat symbols as ABI breakage. The upstream glibc abilist files should be for the default supported configuration. Downstream distros should patch the abilist to match their configuration changes.
On 04/18/2017 06:18 PM, Joseph Myers wrote: > On Thu, 13 Apr 2017, Florian Weimer wrote: > >> I've come up with the attached patch to mark compat symbols as such in the >> abilist files. >> >> Do we want to do this? The downside is that when building glibc in certain >> non-standard configurations, some symbols are not compat symbols anymore (the >> prime example is probably --enable-obsolete-rpc). On the other hand, the >> additional verification is valuable. > > I'd consider whether a symbol is a compat symbol to be part of the API, > not the ABI; I don't think it belongs in these files. > > It may well make sense to be able to assert that a particular symbol is > not available for new programs to link against, for either static or > dynamic linking. Or that any given symbol has at most one non-compat > version, in at most one library, except for cases (if any) explicitly > whitelisted as deliberately having public versions in more than one > library. Could you expand on why you think this is not part of the ABI?
On 04/19/2017 04:06 AM, Carlos O'Donell wrote:
> Downstream distros should patch the abilist to match their configuration changes.
I'm not sure if I agree with that. I'd prefer if these files remained
unmodified because differences threaten portability across distributions.
Is anyone except Fedora compiling current glibc versions with the
--enable-obsolete-* flags? Then we'll need a more intelligent ABI
differ. (If it's just Fedora, I'd prefer moving Fedora forward.)
Thanks,
Florian
On Wed, 19 Apr 2017, Carlos O'Donell wrote: > > I'd consider whether a symbol is a compat symbol to be part of the API, > > not the ABI; I don't think it belongs in these files. > > > > It may well make sense to be able to assert that a particular symbol is > > not available for new programs to link against, for either static or > > dynamic linking. Or that any given symbol has at most one non-compat > > version, in at most one library, except for cases (if any) explicitly > > whitelisted as deliberately having public versions in more than one > > library. > > Could you expand on why you think this is not part of the ABI? The ABI is about what (already linked) binaries (executables and shared libraries) work with a given glibc installation. Whether or not a symbol is a compat symbol does not affect which executables and shared libraries work with it. It affects what source code can be built and linked with that glibc, which is an API issue, not an ABI one. (The interface to .o files is not expected to be stable, if e.g. one glibc version uses an implementation-namespace function in an inline function in a header, but a subsequent version removes that inline function and changes that symbol to a compat symbol.)
ABI checks: Mark compat symbols with "<compat>" 2017-04-13 Florian Weimer <fweimer@redhat.com> * scripts/abilist.awk: Mark compat symbols with "<compat>." diff --git a/scripts/abilist.awk b/scripts/abilist.awk index bd740d4..cb17373 100644 --- a/scripts/abilist.awk +++ b/scripts/abilist.awk @@ -46,7 +46,10 @@ $2 == "g" || $2 == "w" && (NF == 7 || NF == 8) { size = " 0x" size; version = $6; symbol = $NF; - gsub(/[()]/, "", version); + weak = version ~ /^\(.*\)$/; + if (weak) { + gsub(/[()]/, "", version); + } # binutils versions up through at least 2.23 have some bugs that # caused STV_HIDDEN symbols to appear in .dynsym, though that is useless. @@ -102,6 +105,10 @@ $2 == "g" || $2 == "w" && (NF == 7 || NF == 8) { if (desc == "") desc = symbol " " type size; + if (weak) { + desc = desc " <compat>"; + } + if (combine) version = soname " " version (combine_fullname ? " " sofullname : "");