This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Distributions still suffering from s390 ABI change problems.
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Aurelien Jarno <aurelien at aurel32 dot net>, Jeff Law <law at redhat dot com>, David Miller <davem at davemloft dot net>, "krebbel at linux dot vnet dot ibm dot com" <krebbel at linux dot vnet dot ibm dot com>, "roland at hack dot frob dot com" <roland at hack dot frob dot com>, "siddhesh at redhat dot com" <siddhesh at redhat dot com>, "allan at archlinux dot org" <allan at archlinux dot org>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Tue, 15 Jul 2014 11:19:56 +0100
- Subject: Re: Distributions still suffering from s390 ABI change problems.
- Authentication-results: sourceware.org; auth=none
- References: <53C43A5E dot 9020304 at redhat dot com> <20140714 dot 132444 dot 140785163900092398 dot davem at davemloft dot net> <53C440FF dot 3010308 at redhat dot com> <20140714 dot 140948 dot 808129071568411651 dot davem at davemloft dot net> <53C449C0 dot 50709 at redhat dot com> <53C4C14E dot 30908 at redhat dot com> <20140715074223 dot GC32518 at hall dot aurel32 dot net> <53C4DF4F dot 2080102 at redhat dot com>
On 15/07/14 08:59, Carlos O'Donell wrote:
> On 07/15/2014 03:42 AM, Aurelien Jarno wrote:
>> On Tue, Jul 15, 2014 at 01:51:10AM -0400, Carlos O'Donell wrote:
>>> I just tested for x86-64 and loading two libc's in a mixed
>>> environment results in a completely broken image because the
>>> two libc's don't know about eachother and don't coordinate
>>> the implmenetation of things like TLS.
>>>
>>> Therefore I think for libc we can't SONAME bump and we should
>>> instead be aiming to detect the incompatible ABI change and
>>> simply refuse to run the application.
>>
>> The idea of bumping the SONAME, is to have two co-existing installations
>> of the same architecture, using a different libc. A program would use
>> either one or the other. This would make the upgrade process easier and
>> allow users to keep the old libc for running old code until everything
>> is migrated.
>>
>> A check to make sure both libc can't be loaded at the same time should
>> be added, but for the packages, it should be the responsibility of the
>> package manager.
>
> I'd rather extend the .gnu.attributes ABI tags to handle this more
> cleanly.
>
The .gnu.attributes tag system is derived from the scheme ARM developed
for tagging object files. The encoding is quite dense and was not
really intended for use in executables or DSOs.
It might be better to look at other appropriate schemes that guarantee
that the relevant information is placed by the linker in the first page
of the image; that way the loader can guarantee to read the information
quickly when mapping the first page of the image - something it already
has to do anyway.
R.