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: Aurelien Jarno <aurelien at aurel32 dot net>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Jeff Law <law at redhat dot com>, David Miller <davem at davemloft dot net>, krebbel at linux dot vnet dot ibm dot com, roland at hack dot frob dot com, allan at archlinux dot org, libc-alpha at sourceware dot org
- Date: Tue, 15 Jul 2014 11:58:38 +0200
- 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> <20140715084921 dot GF17822 at spoyarek dot pnq dot redhat dot com>
On Tue, Jul 15, 2014 at 02:19:21PM +0530, Siddhesh Poyarekar wrote:
> On Tue, Jul 15, 2014 at 09:42:24AM +0200, Aurelien Jarno wrote:
> > Indeed, that implies a bootstrap almost like for a new architecture,
> > except the manual bootstrap can be done more easily. That's why I talked
> > about "huge work" in the other mail.
>
> The question is if it is worth doing all this. SONAME bumps or hacks
> to the dynamic linker will still not fixed binaries that were built on
> 2.19 and expected that ABI to be present in libc.so.6. Instead of
> adding such convoluted hackery to support what is fundamentally a
> breakage which should never have happened, we should just reverse that
> breakage and introduce the hardware support in a different
> non-ABI-breaking manner, maybe in 2.21.
Indeed that's also a good alternative.
In addition understanding why this structure has to be extended instead
of "needed for future hardware" might help to really understand the
problem and look for alternative solutions. On x86_64 a lot of more
registers have been added (ymm registers and soon zmm registers) without
extending this structure. They are just not preserved through function
calls, so it's not necessary to save them.
Ideally even if we really go for the ABI break, it should only happen
when we actually add support for this hardware. It's always easier to
accept this kind of breakages (especially from the end user point of
view) when it is to add a new killer feature.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net