* Helmut Grohne: > Hi Florian, > > On Fri, Dec 03, 2021 at 06:29:33PM +0100, Florian Weimer wrote: >> We can add a generic ELF parser to that ld.so and use PT_INTERP, as I >> mentioned below. I think this is the way to go. Some care will be >> needed to avoid endless loops, but that should be it. > > Can I ask you to go into a bit more technical detail as to how this is > supposed to work?
Sure! > From what was said, I expect that /usr/bin/ld.so is an ELF executable. > It will likely be part of libc-bin. Do you confirm? Yes, that's what I expect as well. > Since libc-bin is Multi-Arch: foreign. The new ld.so really must have an > architecture-independent API. If it does not, it must not go there. It is as architecture-independent as ldconfig or getconf. Perhaps a bit more so than getconf. > As far as I understand things, the typical use will be "ld.so > --preload somelib someprogram". Now consider an i386 ld.so, an amd64 > somelib and an amd64 someprogram. Will that work with the generic ELF > parser? > > At present, it does not seem to work: > > $ /lib/ld-linux.so.2 --preload /usr/lib/x86_64-linux-gnu/libeatmydata.so > /bin/true > /bin/true: error while loading shared libraries: /bin/true: wrong ELF class: > ELFCLASS64 > $ As has explained elsewhere, you need to use $LIB or just the soname (so that ld.so searches the right paths). I expect this to work eventually: ld.so --preload libeatmydata.so /bin/true Even if /bin/true is an i386 program, assuming that libeatmydata1:i386 is installed. Whether ld.so is built for i386 or amd64 will not matter. > If that is what you will get from /usr/bin/ld.so, then it must not be > part of libc-bin or Multi-Arch: foreign must be dropped. The latter > likely is a non-option due to the amount of resulting breakage. With the patch I've posted, you'll get the ELFCLASS64 error. But I have some ideas how to fix that eventually. Is this sufficient for now? Thanks, Florian