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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Steve McIntyre <steve dot mcintyre at linaro dot org>
- 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: Wed, 29 Jan 2014 01:42:23 +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> <20140128183843 dot GT21103 at linaro dot org>
On Tue, 28 Jan 2014, Steve McIntyre wrote:
> >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?
I've looked at the old cross-ldconfig changes - which only allowed
building a cross-ldconfig that supported a single target at a time, not a
multi-target ldconfig. (I don't think the actual patches - of which what
I have may well be an old version - will be relevant to making ldconfig
multi-target; they just serve to point out some of the issues arising.)
* Various code in ldconfig needs to handle ELF file fields possibly being
the wrong endianness (so it can't just access data loaded from the file
directly).
* The old changes appear to make _dl_cache_check_flags available to the
cross-ldconfig though I don't see an obvious current reason for it to be
needed.
* Of course you need the readelflib.c support for all ABIs - and remember
if building a separate cache for each ABI that some shared libraries might
be ambiguous (supported for more than one ABI variant) and some ABIs may
support libraries with / without certain ELF header markings, so the
present flags don't map to separate ABIs in a very straightforward fashion
(maybe instead the architecture needs to provide a list of ABIs with which
a library is compatible, or something like that).
* ldconfig uses dl-procinfo.h and dl-procinfo.c, so a range of
architecture-specific HWCAP information is needed.
* ldconfig.h provides SYSDEP_KNOWN_INTERPRETER_NAMES and
SYSDEP_KNOWN_LIBRARY_NAMES.
* readlib.c uses LD_SO, LIBC_SO and LIBM_SO from gnu/lib-names.h - and
even the present way of generating that for e.g. 32-bit/64-bit
configurations is a mess, duplicating information in the makefiles and
shlib-versions, let alone defining some way to enumerate those values for
every ABI supported by glibc.
No doubt it's possible to resolve all these issues, and have some
equivalent of elf.h - a shared file or files with the relevant information
for all ABIs supported by glibc about how to identify the ABIs with which
a binary is compatible - given consensus that doing so is desirable at
all. But there do seem to be a fair number of such system dependencies.
--
Joseph S. Myers
joseph@codesourcery.com