qemu-s390x
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qemu-s390x] [Qemu-devel] linux-user: s390x issue on Fedora 30 (dyna


From: Peter Maydell
Subject: Re: [qemu-s390x] [Qemu-devel] linux-user: s390x issue on Fedora 30 (dynamic library loader?)
Date: Mon, 19 Aug 2019 14:44:26 +0100

On Mon, 19 Aug 2019 at 14:34, Aleksandar Markovic
<address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]