[RFC] Multi-arch capable ldconfig

[Markus Mayer <mmayer at broadcom dot com>]

Hi all,

We have recently come across the need for a multi-architecture capable
ldconfig binary, specifically we needed an ldconfig that runs on x86,
but can process shared libraries for ARM and ARM64. The purpose of
this setup is to include generating ld.so.cache in the build process
that runs on an x86 host and generates a root file system for ARM or
ARM64. Since all other parts of the toolchain are already available as
cross-tools, it was natural to look for an ldconfig that can do the
same. This way, we get a root file system that can run on the target
out of the box.

In the end, I found several discussions, but no single solution. This
surprised me, since cross-compilation for embedded systems is rather
common. I expected this issue to have come up before and was sure I'd
find an existing solution. Eventually, I started playing around with
it myself. I came up with an approach that seems much more straight
forward than I initially expected.

See https://github.com/mmayer/glibc/commits/x86_with_arm

It's just two patches. One is merely an include guard for
elf/readelflib.c, so it doesn't end up being included multiple times.
The other patch includes the "arm" ELF parser file into the x86
version of the file.

Let me briefly show the main parts of the patch series.

At the top level in .../i386/readelflib.c:

#define SKIP_READELF_INCLUDE
// re-map the name of process_elf_file() in arm/readelflib.c
#define process_elf_file process_elf_file_arm
#include "sysdeps/unix/sysv/linux/arm/readelflib.c"
#undef process_elf_file
#undef SKIP_READELF_INCLUDE

And in process_elf_file() below:

...
switch (elf_header->e_machine)
{
case EM_ARM:
case EM_AARCH64:
    /* Call the ARM parser for ARM & AArch64. Skip the x86 code by exiting. */
    ret = process_elf_file_arm (file_name, lib, flag, osversion, soname,
        file_contents, file_length);
    return ret;
case EM_X86_64:
...

While this approach seems to work just fine, it is obviously limited
to ARM/ARM64 on x86, which is not a true solution to the issue. One
would want ldconfig to be able to process *ALL* architectures it
supports and it should be able to do this on *ALL* targets it can be
compiled for.

I believe the approach I demonstrated could be generalized for all
architectures rather easily. I am picturing it to look somewhat like
this:

- a "configure" option to turn on the multi-platform capability (it's
off by default)
- there's a sysdeps/unix/sysv/linux/multiplatform/readelflib.c or similar
- this multi-platform readelflib.c includes all the platform specific
readelflib.c files (as I did with just ARM)
- the multi-platform readelflib.c doesn't do any ELF parsing itself;
it just looks at the machine type and calls the platform-specific ELF
parser before returning
- if the "multi-platform" option in configure is turned on, the system
will build multiplatform/readelflib.c rather than any of the
platform-specific versions
- if the "multi-platform" option in configure is not turned on,
multiplatform/readelflib.c will not be built but the platform-specific
version will be used as it is now

Does this sound like a feasible approach? Would it be acceptable for
inclusion in the official glibc distribution? I am sure it would come
in handy in the future if this capability existed.

If it does sound acceptable, would you mind giving me some pointers
how I would tell the make file system to use
multiplatform/readelflib.c rather than the system specific version? I
have to admit I am having some difficulties understanding how "make"
derives the dependencies and decides what to build and in what order
(which is why I stuck everything into i386/readelflib.c for the demo,
so I wouldn't have to worry about "make").

Thanks,
-Marks