Compat symbols in abilist files

Submitted by Florian Weimer on April 13, 2017, 1:09 p.m.

Details

Message ID 6453f4f9-75b5-68b9-0e6b-22f40aaee599@redhat.com
State New
Headers show

Commit Message

Florian Weimer April 13, 2017, 1:09 p.m.
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

Andreas Schwab April 13, 2017, 1:16 p.m.
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.
Florian Weimer April 13, 2017, 1:20 p.m.
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
Joseph S. Myers April 18, 2017, 10:18 p.m.
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.
Carlos O'Donell April 19, 2017, 2:06 a.m.
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.
Carlos O'Donell April 19, 2017, 2:10 a.m.
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?
Florian Weimer April 19, 2017, 7 a.m.
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
Joseph S. Myers April 19, 2017, 9:46 a.m.
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.)

Patch hide | download patch | download mbox

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 : "");