From: Florian Weimer <fweimer@redhat.com>
To: Andreas Schwab <schwab@linux-m68k.org>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH] Fix glibc 2.34 ABI omission (missing GLIBC_2.34 in dynamic loader)
Date: Thu, 13 Jan 2022 18:32:21 +0100 [thread overview]
Message-ID: <87zgnzy21m.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <87y2497rp5.fsf@oldenburg.str.redhat.com> (Florian Weimer via Libc-alpha's message of "Fri, 24 Dec 2021 20:01:26 +0100")
* Florian Weimer via Libc-alpha:
> * Florian Weimer via Libc-alpha:
>
>> * Andreas Schwab:
>>
>>> On Dez 08 2021, Florian Weimer wrote:
>>>
>>>> * Andreas Schwab:
>>>>
>>>>> On Dez 08 2021, Florian Weimer via Libc-alpha wrote:
>>>>>
>>>>>> The glibc 2.34 release really should have added a GLIBC_2.34
>>>>>> symbol to the dynamic loader.
>>>>>
>>>>> Well, the ship has sailed.
>>>>
>>>> Has it? It's just software, we can change it.
>>>
>>> ABI is not software, it's a contract.
>>
>> But sometimes we have to to fix bugs. Again, what I propose is quite
>> different from a simple symbol change because distributions and users
>> can fix this now, well before the symbol is going to be used.
>>
>> I have considered using a stub DSO and mention that instead of libc.so.6
>> in the libc.so linker script. But I'm not sure how we can prevent users
>> from linking against the moved symbol by bypassing the linker script.
>> That would produce ABI-incompatible binaries. We could turn it into a
>> compat symbol, but as long as it's in the dynamic symbol table, some
>> people will use it.
>
> Let me propose a look at this from a different angle.
>
> Let's say we do not apply this change. Then if we move dlopen (say)
> into ld.so, it needs to have a new symbol version, say dlopen@GLIBC_2.36
> (to enable early errors on old glibc even with lazy binding). The net
> result will be that dlopen-using binaries linked against glibc 2.36 or
> later will not work with glibc 2.34.
>
> Binaries linked against glibc 2.34 with or without the proposed change
> are fully interoperable (forwards and backwards compatible). No new
> symbol version/soname combination is ever generated by the link editor
> because the GLIBC_2.34 version in ld.so is effectively empty.
> Considering the moved dlopen, we would give it version of
> dlopen@GLIBC_2.34 (even if the symbol is added in glibc 2.36). Binaries
> linked against glibc 2.36 will still fail when running at the initial
> version of glibc 2.34. But with the proposed patch here, they will work
> even with glibc 2.34. This means that there are no ABI
> incompatibilities introduce by this patch, and we enable compatibility
> with future symbol moves.
Andreas, do you find this line of reasoning convincing?
Thanks,
Florian
next prev parent reply other threads:[~2022-01-13 17:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-08 9:46 Florian Weimer
2021-12-08 9:56 ` Andreas Schwab
2021-12-08 10:06 ` Florian Weimer
2021-12-08 10:20 ` Andreas Schwab
2021-12-08 10:28 ` Florian Weimer
2021-12-08 14:06 ` H.J. Lu
2021-12-24 19:01 ` Florian Weimer
2022-01-13 17:22 ` Carlos O'Donell
2022-01-13 17:32 ` Florian Weimer [this message]
2021-12-08 16:59 ` Siddhesh Poyarekar
2021-12-13 12:15 ` Florian Weimer
2021-12-13 14:54 ` Siddhesh Poyarekar
2022-01-13 17:56 ` Carlos O'Donell
2022-01-13 18:00 ` Carlos O'Donell
2022-01-22 16:08 ` H.J. Lu
2022-01-24 14:31 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zgnzy21m.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=schwab@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).