Multiarch paths and toolchain implications
loic.minier at linaro.org
Mon Aug 2 16:30:05 BST 2010
On Mon, Aug 02, 2010, Ulrich Weigand wrote:
> Agreed. Not sure what this particular divergence helps ...
So Matthias mentionned that gnat and gcc are not always using the same
minor version, and so it helps bootstrap them to have the common bits
installable without overly strict dependencies. I wonder whether we
could do that properly upstream. We should chat with Matthias on the
next occasion and write down a plan.
> > I see two ways around this; we could patch the kernel to add a dynamic
> > prefix before the runtime-linker path depending on the executable
> > contents (typically depending on the arch),
> This seems awkward.
> > or more elegantly we could
> > have a generic loader which checks the architecture of the target ELF
> > file before calling the arch-specific loader. This loader would be
> > linked to from all the old locations.
> Well, but then what architecture would that generic loader be in? In the
> end, it has to be *something* the kernel understands to load natively.
Currently with binfmt_misc when the kernel loads a binary it will check
whether it's the native architecture and if it is load the ELF dynamic
linker referenced in the binary; if it matches one of the regexps from
binfmt_misc, such as the binary pattern for ARM ELF binaries, it will
call the binfmt interpreter instead, e.g. qemu-arm, and in this case
qemu-arm will load the ELF runtime linker of the target binary to run
the binary inside the CPU emulation.
So I think this should just work; the kernel will call the native ELF
loader of the current arch for binaries for the current arch, and will
load QEMU which will load and emulate the ELF loader for the emulated
arch in the other cases.
Perhaps I should work with Steve at prototyping this to make sure this
> > The reason I'm thinking of patching the kernel is because binfmt_misc
> > is already out there and allows special behavior when encountering
> > binary files from other architectures (or any binary pattern really).
> But binfmt_misc only works because in the end it falls back to the built-
> in native ELF loader. (You can install arbitrary handlers, but the
> handlers themselves must in the end be something the kernel already
> knows how to load.)
Is your point that we should disable the qemu loader for the native
architecture? I certainly agree we need to!
> Yes, that's during compile time. I understand the reason for this is more
> to catch bad include paths manually specified in packages. Not sure if
> during load time the same concerns apply.
Ok; I kind of agree that runtime is a different story
More information about the linaro-toolchain