Re: [Qemu-devel] [qemu-s390x] linux-user: s390x issue on Fedora 30 (dynamic library loader?)

[Peter Maydell <peter.maydell@linaro.org>]

On Mon, 19 Aug 2019 at 14:34, Aleksandar Markovic
<aleksandar.m.mail@gmail.com> wrote:
> I can't repro the problem either, but I do have a patch authored by an engineer that left the company a while ago that seems to be at least related to your scenario. May I ask you to test it (just apply it to QEMU ToT and rerun the scenario to see if it changes the outcome) (feel free to experiment and modify the changes)? I never managed to understand the purpose of that patch (I lost the contact with the former engineer, and the patch is without any comment), so I never dared to send it to the list, but I hope your scenario may actually explain the purpose and the origin of the patch.

It's basically a more complete implementation of the
suggestion from https://bugs.launchpad.net/qemu/+bug/1701798
comment #9 (it covers more syscalls and returns a valid
guest errno rather than a host one). The intention, as
you've guessed, is to paper over this guest-ld.so bug by
preventing it from being able to open /etc/ld.so.cache at
all (which will make it fall back to working without a cache).

My feelings about it are the same as they were when I wrote
comment #10 in reply: that patch would prevent us from picking up
a legitimate ld.so.cache for the guest (in a chroot, for instance.
I'm also not a fan of trying to work around specific guest code
issues: I'd much rather this was just fixed in ld.so where it ought
to be.

You should be able to repro this bug on real hardware by
copying an x86-64 ld.so.cache onto a big-endian machine :-)

thanks
-- PMM