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 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
