Loïc Minier <loic.min...@linaro.org> wrote: > Awesome analysis!
Thanks! > So I think you analyzed the upstream toolchain behavior Yes, that's true. > and I think > Debian/Ubuntu toolchains cheat in some areas; for some directories > which would use $(version) we use $(major).$(minor) instead, and we > have a $(version) -> $(major).$(minor) symlink. This doesn't really > relate to the multiarch topic, but it reminds me that we ought to fix > the distro divergences so that it's easier to swap an upstream > toolchain with a Debian/Ubuntu one and vice-versa. Agreed. Not sure what this particular divergence helps ... > > Executables built with the old ELF interpreter will not run on a > > system that *only* provides the multiarch install location. This > > is clearly *not* OK. To provide backwards compatibility, even a > > multiarch-capable system will need to install ELF interpreters > > at the old locations as well, possibly via symlinks. (Note that > > any given system can only be compatible in this way with *one* > > architecture, except for lucky circumstances.) > > 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. The ELF interpreter location is encoded as full path, which is not interpreted in any way by the kernel. We'd either have to encode particular filesystem layout knowledge into the kernel here, or else add a prefix at the very beginning (or end?), which doesn't correspond to the scheme suggested for multiarch. If we go down that route, it might be easier to use tricks like bind- mounting the correct ld.so for this architecture at the default location during early startup or something ... However, I'd have thought the whole point of the multiarch scheme was to *avoid* having to play filename remapping tricks, but instead make all filenames explicit. > 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. > 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.) > > Option C: ld.so searches both the -rpath as is, and also with > > multiarch target string appended. > > This is a risk for cross-builds; the native version might be picked up. > While this doesn't seem much of a risk for cross-compilation to an > entirely different architecture (e.g. x86 to ARM), consider > cross-builds from x86-64 to x86, or from EABI + hard-float to EABI + > soft-float. That's one of the fundamental design questions: do we want to make sure only multiarch libraries for the correct arch can ever be found, or do we rather want to make sure on a default install, libraries that have not yet been converted to multiarch can also be found (even taking the chance that they might turn out be of the wrong architecture / variant) ... > BTW, the CodeSourcery patchset contains a "directory poisoning" feature > which seems quite useful to detect these cases early. 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. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
