This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Policy: Require new dynamic loader names for entirely new ABIs?


[ 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]