Compat symbols in abilist files

[Florian Weimer]

* Joseph Myers:

> On Wed, 17 Mar 2021, Florian Weimer via Libc-alpha wrote:
>
>> I'd like to re-raise the matter of comapt symbol markers in abilist
>> files.
>> 
>> --enable-obsolete-rpc (which changed compat symbol status) is gone,
>> which should simplify matters.
>
> Might we have other such options in future?

Hard to tell.  I think the experience with --enable-obsolete-rpc wasn't
altogether positive.  The transition took far too long.

If I saw the sequence of changes, --enable-obsolete-rpc was added as a
stopgap measure after too much broke.  I suspect that won't happen
again, in that we would try hard to get distributions to move first.

>> Joseph, you objected to this in the past.  While reviewing libpthread
>> symbol moves, I noticed that when going from
>
> I think my argument was that whether a symbol is a compat symbol is not 
> part of the ABI (it doesn't affect which executables or shared libraries 
> will work with a given glibc build).

I think it's part of the link-time ABI, which in turn affects the
run-time ABI of the linked binaries.  There is definitely a
compatibility impact here, in the sense that the wrong choice of default
symbol version can cause breakage in the field (although not when
running against the same glibc to which the link happened).

> So the question is: do we want this information in the abilist files even 
> though it's not part of the ABI?

I think we have cases where compat symbols are universal because we
entirely deprecated an interface (e.g., loc1).  Those could be handled
separately.  Others are highly version-dependent, and describing that
concisely would likely encounter similar complexity than what we have in
the sources (e.g., pread).  Then there are things that are completely
target-specific, like the s390x symbol situation around glibc 2.19.
Data for that would have to live in some target-specific list in any
case.

Given that, putting a compat (C?) flag into the existing abilist files
looks like a pragmatic solution to me.

> I expect many patches that change this information would need to change 
> abilist files anyway (the exception being a patch that purely marks 
> symbols as compat symbols, without adding any new versions of those 
> symbols).

One case I mentioned in my first message is another exception.  When we
move a symbol from libc that has a higher version, like this:

  libc:  pread@@GLIBC_2.1   libpthread: pread@@GLIBC_2.2

we can get away without a new symbol version at the current glibc
version, if we go to this:

  libc:  pread@@GLIBC_2.1 pread@GLIBC_2.2

Then it is totally not apparent from the abilist whether we have the
right default symbol version.  For the usual case,

  libc:  pread@GLIBC_2.1 pread@GLIBC_2.2 pread@@GLIBC_2.34

it's more obvious.  But with the retroactive update, we could also end
up by accident with:

  libc:  pread@GLIBC_2.1 pread@@GLIBC_2.2

and that would be slightly inaccurate.

Patches that change symbol management globally (like the one I posted
today) would also benefit greatly from that little extra data in the
*.abilist files, I think.

Thanks,
Florian