This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Policy: Require new dynamic loader names for entirely new ABIs?
- From: Steve McIntyre <steve dot mcintyre at linaro dot org>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Andrew Pinski <pinskia at gmail dot com>, Marcus Shawcroft <marcus dot shawcroft at gmail dot com>, "Ryan S. Arnold" <ryan dot arnold at linaro dot org>, Doug Gilmore <Doug dot Gilmore at imgtec dot com>, sandra at codesourcery dot com, cltang at codesourcery dot com
- Date: Tue, 28 Jan 2014 18:38:43 +0000
- Subject: Re: Policy: Require new dynamic loader names for entirely new ABIs?
- Authentication-results: sourceware.org; auth=none
- References: <52DD4BB8 dot 1090901 at redhat dot com> <52DD56C8 dot 109 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1401212208100 dot 25161 at digraph dot polyomino dot org dot uk> <52DF3E13 dot 6050408 at redhat dot com> <20140123102506 dot GM21103 at linaro dot org> <Pine dot LNX dot 4 dot 64 dot 1401231441340 dot 27866 at digraph dot polyomino dot org dot uk>
[ Apologies for not responding sooner - I've had this half-written for
several days... ]
On Thu, Jan 23, 2014 at 02:59:19PM +0000, Joseph S. Myers wrote:
>On Thu, 23 Jan 2014, Steve McIntyre wrote:
>
>> * Could/should we change ldconfig to deal with all the ELF libraries
>> it finds in the system search paths, regardless of architecture and
>> ABI? I see nothing inherently difficult with this: all the ELF
>> header parsing code is already portable and AFAICS it shouldn't
>> care at all about the platform of the libraries it finds.
>
>I'm sure in principle this could be done - taking all the
>architecture-specific code to identify ABI variants and putting it
>somewhere central, much like elf.h is a central file with information on
>all architectures. I'm not sure how simple it is, however. See the
>comments on cross-ldconfig at
><https://sourceware.org/glibc/wiki/Development_Todo/Master#Cross_build_.2BAC8_test_improvements>.
OK.
>It could be that changing the code to be multi-arch friendly would be
>simpler than building cross-ldconfig under constraints to avoid large
>changes to the underlying code.
Right, that's what I'm thinking. Unless there are some obscure
architecture-dependent pieces in ldconfig that I haven't seen yet?
>(And some ABIs don't currently have any good way to distinguish them
>through the ELF headers, e.g. powerpc soft-float / hard-float, so would
>need to share a cache until appropriate ELF header flags are defined and
>implemented.)
ACK, makes sense.
>> * Should we then split the cache up into multiple files, one per
>> arch/ABI? (In fact, one per distinct loader?) This would remove any
>> potential issues with collisions and should make things simpler and
>> maybe faster as far as I can see - in multiple-ABI cases each
>> loader will have a smaller search space when looking for libraries.
>
>ldconfig will, for relevant architectures, handle libc4/libc5 libraries as
>well as those built with glibc.
>
>We need to avoid breaking running binaries built with those libraries,
>although we don't need to optimize anything for them. Did they require
>the cache to be present in order to find libraries (rather than it simply
>being an optimization)? If so, that may limit the changes that can be
>made, because ld.so.cache will need to remain usable by libc4/libc5,
>although glibc could certainly stop reading it, instead using newer files,
>and I suppose ld.so.cache could contain *only* the data needed by the old
>libraries (i.e. information about same-architecture libc4/libc5 files).
>See sysdeps/generic/dl-cache.h, "libc5 and glibc 2.0/2.1 use the same
>format. For glibc 2.2 another format has been added in a compatible way
>..." for information on existing compatibility handling.
Yes, I've read that piece a few times and I was thinking *exactly*
that a move to newer separated files could also benefit us by not
disturbing the legacy bits. It seems like a good point to be able to
declare a break and simplify things, maybe improving performance too.
Plus: are there any other changes that people would like if there was
scope for a new cache layout?
>Now, it appears some support for libc4/libc5 is present unconditionally
>rather than only for (the Linux kernel with) architectures needing it.
>If ldconfig is to be properly multi-architecture, I suppose that makes
>sense, however unlikely it is to be running such binaries via emulation on
>another architecture, but otherwise it might be conditioned out.
>Specifically, it's only relevant for m68k and i386, and x86_64 and maybe
>ia64 for running i386 binaries; libc4 and libc5 didn't support other
>architectures.
ACK. Keep default behaviour to organise things that way, but add
options such as "--all-arches" or "arches=arch1,arch2,..." or similar
to turn on new behaviour?
Cheers,
--
Steve McIntyre steve.mcintyre@linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs