Multiarch paths and toolchain implications

[Loïc Minier]

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.

 Agreed

> >  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
 works.

> >  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

-- 
Loïc Minier