Jonathan Nieder <jrnie...@gmail.com> writes: > severity 658278 wishlist > tags 658278 + moreinfo > quit > > Goswin von Brederlow wrote: > >> It has a different interpreter in its elf section. Ld.so could check >> that to determine wether the elf file is one it should care about. > > A common use case is testing updated versions of ld.so by running > binaries explicitly using the ld.so binary. I don't see how your > proposed enhancement is consistent with that.
The interpreter listed in the elf binary would still match /lib64/ld-linux-x86-64.so.2 (or whatever it is on the arch) even if you explicitly call an ld.so from a different location. My suggestion isn't to match against the location the ld.so currently holds but against the location the ld.so is supposed to be in, where it would install to. >> A segfault is never correct behaviour and needs to be fixed in ld.so. > > If my program is built against one DSO and the caller uses LD_PRELOAD > or LD_LIBRARY_PATH to replace it with something completely different, > I'd expect segfaults from time to time (due to incompatible struct > layouts, for example). In those cases the binary segfaults and that is unavoidable. But in this case the ld.so itself crashes. > However, maybe it is avoidable. Often that kind of misconfiguration > gets caught by other checks, like the following: > > foo: symbol lookup error: foo: undefined symbol: some_symbol > > Before veering too far in that direction, what is your use case? Was > something broken by this? Maybe there is a simpler way to accomplish > it. Nothing specific. We stumbled across it trying to fix a remote system after an accident with "rm -rf /". MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org