My last comment ("The issue seems to be fixed, even without the symlink
for /usr/-linux-gnu/etc/ld.so.cache.") was incorrect. When this
symlink is set, the program accesses /etc/ld.so.cache after accessing
/usr/-linux-gnu/etc/ld.so.cache. In some cases, it works, in some
cases it doesn't — dependin
The issue seems to be fixed, even without the symlink for
/usr/-linux-gnu/etc/ld.so.cache.
For m68k: since version 2.10.0.
For s390x: since version 2.11.0.
For the other platforms, already since 2.9.0 (strange, this contradicts my
original report...).
** Changed in: qemu
Status: Incomplet
The QEMU project is currently considering to move its bug tracking to
another system. For this we need to know which bugs are still valid
and which could be closed already. Thus we are setting older bugs to
"Incomplete" now.
If you still think this bug report here is valid, then please switch
the
Did we open a precise glibc upstream bug for this so I can go upvote it?
:-)
Workaround from #12 also worked for me.
Tested on Buildroot with this precise setup:
https://github.com/cirosantilli/linux-kernel-module-
cheat/tree/e855a262fd872171156894e9045814cb0f346dab#stack-smashing-
detected
For
I believe this same bug affects me on Linux Mint 18.3 Sylvia which is based on
Ubuntu Xenial.
The suggestion from #12 helped me. Thank you @bruno-clisp!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/
My feeling is that glibc upstream will not want to care about cross qemu
situations. I would prefer to report it to the Ubuntu cross-tools
maintainers: The package libc6--cross contains the file /usr/-linux-gnu/lib/libc.so.6; they could surely add the symlink for
/usr/-linux-gnu/etc/ld.so.cache as
I still feel we shouldn't be working around guest code bugs in QEMU, so
I'm not sure there's anything more for QEMU to do here. You should
report the dynamic linker bug to glibc upstream.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU
> You can probably also work around this by creating an empty
ld.so.cache in the QEMU_LD_PREFIX directory, though it's awkward if you
wanted that to be the /usr/whatever directory.
Indeed, qemu already analyzes the QEMU_LD_PREFIX, stores a cache of its
contents in the static variable 'base', and u
> That patch would prevent us from picking up a legitimate ld.so.cache for the
> guest (in a chroot, for instance), so I don't think we should take it.
But in a chroot, QEMU_LD_PREFIX is most likely NOT set. So how about this
pseudocode?
if (strcmp (pathname, "/etc/ld.so.cache") == 0 && getenv
That patch would prevent us from picking up a legitimate ld.so.cache for
the guest (in a chroot, for instance), so I don't think we should take
it. (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, so I'd enco
Re #4:
> 2) files like /etc/ld.so.cache (and other things the dynamic linker uses)
> are not in the -L directory but are in the host
> 3) the ld.so.cache format is not endian-agnostic
> 4) glibc's dynamic linker code does not ignore a wrong-endian ld.so.cache
> but crashes instead
Indeed the
> can you still reproduce any of the other problems with a new QEMU?
On the same system (Ubuntu 16.04 x86_64, not a chroot environment), I
still observe the same symptoms with QEMU as of today than with 2.9.0 or
2.10.0:
$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-sparc64
h
This patch fixes the s390 issue:
https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg01103.html
which is the only part of this (ignoring m68k) that I could reproduce.
Bruno: can you still reproduce any of the other problems with a new
QEMU?
--
You received this bug notification because you
I just tested with powerpc and current head-of-git QEMU and it works:
e104462:xenial:bug-1701798$ cat hello.c
#include
int main(void) {
printf("hello world\n");
return 0;
}
e104462:xenial:bug-1701798$ powerpc-linux-gnu-gcc-5 -O hello.c -o hello.powerpc
e104462:xenial:bug-1701798$ QEMU_LD_
** Tags added: linux-user
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1701798
Title:
dynamically linked binaries crash for big-endian targets
Status in QEMU:
New
Bug description:
On the tar
For s390x, the hang definitely still occurs using a chroot with qemu-
s390x-static copied in and no QEMU_LD_PREFIX. I'm not in a good position
to test other big-endian architectures though.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QE
Can you check whether these work if you copy the QEMU and the dynamically
linked target binary into a chroot (which does not have the x86 host ld.so or
/etc in it) instead of using QEMU_LD_PREFIX ? There is a problem I've seen
before where:
1) QEMU when run with QEMU_LD_PREFIX or -L works by "f
The behaviour in qemu-2.10 is nearly the same as in qemu-2.9. The only
difference is a different kind of crash for m68k:
$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020
~/inst-qemu/2.9.0/bin/qemu-m68k hello.m68k
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
$ QEMU_LD_PR
I think I hit this problem trying to use qemu-s390x-static in the
s390x/ubuntu:16.04 docker image. Running qemu-s390x-static 2.9.0 on
binaries in that image (e.g. /bin/echo) results in a hang.
I've noticed that doing the same in a s390x/debian:jessie image does NOT
have the same problem. No hang.
I would guess that the problem comes from a missing (or an extra) BSWAP call in
one of the files
include/elf.h
include/hw/elf_ops.h
linux-user/elfload.c
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net
20 matches
Mail list logo
