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

[Peter Maydell]

On Sat, 17 Aug 2019 at 17:14, David Hildenbrand <address@hidden> wrote:
>
> On 17.08.19 17:59, David Hildenbrand wrote:
> > Hi everybody,
> >
> > I was just trying to run qemu-s390x (linux-user) with a very simple
> > binary (gzip + lib/ld64.so.1, compiled under Fedora 27). This used to
> > work just fine a while ago (especially when I was working on vector
> > instructions using QEMU v3.1). However, now I can't get past a SEGFAULT
> > in the dynamic library loader (I assume it is trying to locate glibc). I
> > tried a couple of other binaries that definitely used to work (from
> > Fedora 30).
> >
> > I checked QEMU v4.1, v4.0 and v3.1. All are broken for me. Which is
> > weird - because it used to work :/
> >
> > I remember that I was running Fedora 29 the last time I had it running,
> > so my gut feeling is that this is related to some other system library
> > (but which?). I am running on an up-to-date Fedora 30 x86-64 now.
> >
> > Any ideas? Has this been reported already? (not sure if this is a Fedora
> > 30 issue)

I'm pretty sure the problem you've run into is a long standing
bug in the glibc dynamic loader. It cannot cope with the ld.so.cache
being for the wrong endianness. (Correct endianness but incorrect
architecture it correctly detects and ignores). The result is that
running a linux-user QEMU dynamic binary for big-endian on little-endian
like this will crash in the dynamic loader unless you arrange that it can't
find the host's ld.so.cache somehow, eg:
 (a) run inside a chroot
 (b) create an empty /etc/ld.so.cache file inside the -L directory

The ideal fix would be if somebody cared enough to track down
and fix the ld.so bug.

Compare:
https://bugs.launchpad.net/qemu/+bug/1701798
https://bugs.launchpad.net/qemu/+bug/1835693

thanks
-- PMM