* Lennart Poettering: > On Do, 02.12.21 19:38, Florian Weimer (fweimer@xxxxxxxxxx) wrote: > >> It would go into glibc-common on x86-64, and the initial version won't >> be able to launch 32-bit programs (“wrong ELF class: ELFCLASS32”). > > "the initial version"? That phrasing makes me wonder, what longer term > plans do you have in mind for this? i.e. do you intend to support > other archs, and if so, how? Chain-load the right ld.so in case the > binary is not native? Probably execve the other loader using the PT_INTERP path if it exists. We need to avoid an infinite loop; probably we need to splice in a command line option. And we don't want to do this if the first invocation wasn't an explicit loader invocation. So there are a few details to work out for the cross-architecture case. (The execve is needed to trigger binfmt_misc handlers registered with the kernel.) > Another question: in systemd we have code to be able to boot from just > a /usr/ partition, with the root file system being an empty tmpfs > initially. For that to work we have to set up a basic file system > tree, since /usr/ alone is not sufficient — most importantly we have > to set up the right symlinks for /lib/ + /lib64/, since the ELF > interpreter is after all hardcoded in the ELF headers of the various > dynamic binaries in accordance with the ABI of the architecture, and > the ELF interpreter for most archs is placed in /lib/ or > /lib64/. Right now we include a table with the right symlinks we have > to create for each architecture we want to support. If your new > symlink in /usr/bin/ to the right ld.so becomes API though we could > drop this table in the long run, and instead just readlink() your > symlink and thus know which of /lib/ and /lib64/ we actually have to > symlink. Hence my question: do you intend to make this API? i.e. that > this is a symlink? Because only if it's officially API that this is a > symlink (and not a regular file/hardlink) and that it always points to > the interpreter for the primary architecture of the system, in > accordance with the ELF ABI docs we can rely on it. The symbolic link will be relative, so it won't give you the exact path you need to use. I don't know if the glibc installation path (which /usr/bin/ld.so will point to) is the official ABI path for all architectures. It should be, but Fedora had some additional symbolic links there historically. We can likely add the official path to the dynamic linker as a macro in <gnu/lib-names.h>. This will not work for cross-initrd setups, but it will be easier to process than /usr/bin/ld.so than the native case. (The path in <gnu/lib-names.h> will reflect glibc assumptions, so it doesn't help with partial downstream customizations.) For cross-initrd, I think you need to parse the ELF and grab the interpreter path from there. Thanks, Florian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
