Re: [PATCH v2 0/9] target/hppa qemu v8.2 regression fixes

> The whole series can be pulled from the "hppa-fixes-8.2" branch from: > https://github.com/hdeller/qemu-hppa.githppa-fixes-8.2 Tested-by: Bruno Haible

[Bug 1701798] Re: dynamically linked binaries crash for big-endian targets

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 —

[Bug 1912934] Re: QEMU emulation of fmadds instruction on powerpc64le is buggy

The situation is still the same in QEMU 6.0.0. $ powerpc64le-linux-gnu-gcc-5 test-fmadds.c -static $ ~/inst-qemu/6.0.0/bin/qemu-ppc64le ./a.out ; echo $? 32 ** Changed in: qemu Status: Incomplete => New -- You received this bug notification because you are a member of qemu- devel-ml,

[Bug 1705118] Re: qemu user mode: rt signals not implemented for sparc guests

The situation in version 6.0.0 is the same as in version 2.11.0: The cases ppc, ppc64, ppc64le, s390x are fixed, but the sparc64 executable still crashes. ** Changed in: qemu Status: Incomplete => New -- You received this bug notification because you are a member of qemu- devel-ml, which

[Bug 1701798] Re: dynamically linked binaries crash for big-endian targets

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:

[Bug 1892441] Re: "No zIPL section in IPL2 record" error when emulating Debian 10.5.0 on s390x

Yes. For booting Debian images using QEMU (<= 5.0.0) I use this recipe: machine_args="-M s390-ccw-virtio -m 512" disk_args="-drive file=debian86.img,if=none,format=raw,id=hd0 -device virtio-blk-ccw,drive=hd0" net_args="" display_args="-display gtk -monitor stdio" common_args="$machine_args

[Bug 1912934] [NEW] QEMU emulation of fmadds instruction on powerpc64le is buggy

Public bug reported: The attached program test-fmadds.c tests the fmadds instruction on powerpc64le. Result on real hardware (POWER8E processor): $ ./a.out ; echo $? 0 Result in Alpine Linux 3.13/powerpcle, emulated by QEMU 5.0.0 on Ubuntu 16.04: $ ./a.out ; echo $? 32 Result in Debian

[Bug 1883984] Re: QEMU S/390x sqxbr (128-bit IEEE 754 square root) crashes qemu-system-s390x

I confirm that the patch https://lists.gnu.org/archive/html/qemu- s390x/2020-06/msg00213.html fixes the issue, both for qemu-s390x and qemu-system-s390x. Thanks Richard! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Bug 1883984] Re: QEMU S/390x sqxbr (128-bit IEEE 754 square root) crashes qemu-system-s390x

Another way to reproduce this bug is with qemu-s390x and a cross- compiled binary: $ s390x-linux-gnu-gcc-5 -static -o bug-sqrtl-one-line.s390x bug-sqrtl-one-line.c $ qemu-s390x bug-sqrtl-one-line.s390x Segmentation fault (core dumped) Find attached the binary. ** Attachment added: "statically

[Qemu-devel] [Bug 1701835] Re: floating-point operation bugs in qemu-alpha

The patch mentioned in #15 fixes the issue: - The test programs test-cbrt ... test-truncf1 now all succeed. - The test program from comment #6, run with qemu-alpha, prints 680e8000, i.e. bit 59 is set. Thanks Richard!! -- You received this bug notification because you are a member of

[Qemu-devel] [Bug 1701835] Re: floating-point operation bugs in qemu-alpha

The problem is still reproducible with QEMU 4.0.0: - The test programs test-cbrt ... test-truncf1 crash or abort as described. - The test program from comment #6, run with qemu-alpha, prints 600e8000, i.e. bit 59 is unset. -- You received this bug notification because you are a member

[Qemu-devel] [Bug 1701835] Re: floating-point operation bugs in qemu-alpha

No, it is not fixed: even with this patch the program that fetches the fpcr still prints 600e8000, and the various program crashes still occur. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1701835] Re: floating-point operation bugs in qemu-alpha

The fpcr value seen in a process running in a VM comes from the Linux kernel, file linux/arch/alpha/kernel/process.c, function flush_thread(): /* Arrange for each exec'ed process to start off with a clean slate with respect to the FPU. This is all exceptions disabled. */

[Qemu-devel] [Bug 1701835] Re: floating-point operation bugs in qemu-alpha

Under qemu-system-alpha I get 680e8000 as well. Under qemu-alpha (versions 2.8.1, 2.9.0, 2.10.0, 2.11.0, 2.12.0, 3.1.0) I get 600e8000, i.e. bit 59 is unset. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1701835] Re: floating-point operation bugs in qemu-alpha

> You should try building with -mieee. When I build with ../configure CFLAGS="-mieee -O2 -g" CPPFLAGS=-Wall LDFLAGS="-static -lieee" I observe the exact same behaviour: Only 4 tests fail in a VM executed with qemu-system-alpha, whereas the same test failures (from test-cbrt to test-truncf1) are

[Qemu-devel] [Bug 1704658] Re: O_CLOEXEC not handled in dup3 system call in user mode

Confirmed: It's fixed in qemu-2.12. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1704658 Title: O_CLOEXEC not handled in dup3 system call in user mode Status in QEMU: Fix Released Bug

[Qemu-devel] [Bug 1701808] Re: stack smashing in or after recvmsg system call in aarch64 user mode

Confirmed: It's fixed in qemu-2.12. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1701808 Title: stack smashing in or after recvmsg system call in aarch64 user mode Status in QEMU: Fix Released

[Qemu-devel] [Bug 1701798] Re: dynamically linked binaries crash for big-endian targets

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

[Qemu-devel] [Bug 1705118] Re: qemu user mode does not support catching SIGSEGV on some architectures

I confirm that in qemu-2.11, the ppc and s390x cases are fixed, however the sparc64 case is still failing: $ ~/inst-qemu/2.11.0/bin/qemu-ppc testsigsegv-ppc $ echo $? 0 $ ~/inst-qemu/2.11.0/bin/qemu-ppc64 testsigsegv-ppc64 $ echo $? 0 $ ~/inst-qemu/2.11.0/bin/qemu-ppc64le testsigsegv-ppc64le $

[Qemu-devel] [Bug 1701974] Re: pwrite does not work right under qemu-sh4

Works fine in qemu-2.11: $ ~/inst-qemu/2.11.0/bin/qemu-sh4 test-pwrite buf = 01W3456789 ** Changed in: qemu Status: New => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1701974

[Qemu-devel] [Bug 1704658] Re: O_CLOEXEC not handled in dup3 system call in user mode

The behaviour in qemu-2.11 is the same as in qemu-2.9. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1704658 Title: O_CLOEXEC not handled in dup3 system call in user mode Status in QEMU: New

[Qemu-devel] [Bug 1704638] Re: weak symbol access makes qemu in user mode hang for mips, mips64

This is fixed in qemu-2.11: $ ~/inst-qemu/2.11.0/bin/qemu-mips testpthsigmask-mips qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (core dumped) $ ~/inst-qemu/2.11.0/bin/qemu-mips64 testpthsigmask-mips64 qemu: uncaught target signal 11 (Segmentation fault) -

[Qemu-devel] [Bug 1701835] Re: floating-point operation bugs in qemu-alpha

The behaviour in qemu-2.11 is the same as in qemu-2.9. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1701835 Title: floating-point operation bugs in qemu-alpha Status in QEMU: New Bug

[Qemu-devel] [Bug 1701973] Re: pread does not work right under qemu-sh4

With qemu-2.11: $ ~/inst-qemu/2.11.0/bin/qemu-sh4 test-pread ret=1 errno=2 The value of errno is actually irrelevant here. So, the bug is fixed. ** Changed in: qemu Status: New => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is

[Qemu-devel] [Bug 1701808] Re: stack smashing in or after recvmsg system call in aarch64 user mode

The behaviour in qemu-2.11 is the same as in qemu-2.9. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1701808 Title: stack smashing in or after recvmsg system call in aarch64 user mode Status in

[Qemu-devel] [Bug 1701798] Re: dynamically linked binaries crash for big-endian targets

> 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

[Qemu-devel] [Bug 1701798] Re: dynamically linked binaries crash for big-endian targets

> 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 &&

[Qemu-devel] [Bug 1701798] Re: dynamically linked binaries crash for big-endian targets

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

[Qemu-devel] [Bug 1701798] Re: dynamically linked binaries crash for big-endian targets

> 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

[Qemu-devel] [Bug 1705118] Re: qemu user mode does not support catching SIGSEGV on some architectures

The behaviour in qemu-2.10 is the same as in qemu-2.9. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1705118 Title: qemu user mode does not support catching SIGSEGV on some architectures Status

[Qemu-devel] [Bug 1704658] Re: O_CLOEXEC not handled in dup3 system call in user mode

The behaviour in qemu-2.10 is the same as in qemu-2.9. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1704658 Title: O_CLOEXEC not handled in dup3 system call in user mode Status in QEMU: New

[Qemu-devel] [Bug 1701971] Re: multithreading not working right under qemu user mode for sh4

This works fine in qemu-2.10: $ ~/inst-qemu/2.10.0/bin/qemu-sh4 test-tls ... Worker 0xecdff4c0 doing value swapping Worker 0xecdff4c0 doing value swapping Worker 0xecdff4c0 before final verify Worker 0xecdff4c0 after final verify Worker 0xecdff4c0 dying. OK ** Changed in: qemu Status:

[Qemu-devel] [Bug 1701974] Re: pwrite does not work right under qemu-sh4

The behaviour in qemu-2.10 is the same as in qemu-2.9. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1701974 Title: pwrite does not work right under qemu-sh4 Status in QEMU: New Bug

[Qemu-devel] [Bug 1701973] Re: pread does not work right under qemu-sh4

The behaviour in qemu-2.10 is the same as in qemu-2.9. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1701973 Title: pread does not work right under qemu-sh4 Status in QEMU: New Bug

[Qemu-devel] [Bug 1704638] Re: weak symbol access makes qemu in user mode hang for mips, mips64

The behaviour in qemu-2.10 is the same as in qemu-2.9. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1704638 Title: weak symbol access makes qemu in user mode hang for mips, mips64 Status in

[Qemu-devel] [Bug 1701821] Re: floating-point operation bugs in qemu-sh4

With qemu-2.10, all of these tests now pass. Great! ** Changed in: qemu Status: New => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1701821 Title: floating-point operation

[Qemu-devel] [Bug 1701808] Re: stack smashing in or after recvmsg system call in aarch64 user mode

The behaviour in qemu-2.10 is the same as in qemu-2.9. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1701808 Title: stack smashing in or after recvmsg system call in aarch64 user mode Status in

[Qemu-devel] [Bug 1701798] Re: dynamically linked binaries crash for big-endian targets

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-devel] [Bug 1705118] Re: qemu user mode does not support catching SIGSEGV on some architectures

** Attachment added: "Statically compiled test program for ppc64" https://bugs.launchpad.net/qemu/+bug/1705118/+attachment/4917118/+files/testsigsegv-ppc64 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1705118] [NEW] qemu user mode does not support catching SIGSEGV on some architectures

Public bug reported: The documentation says that qemu in user mode supports POSIX signal handling. Catching SIGSEGV according to POSIX, however, does not work on ppc, ppc64, ppc64le, s390x, sparc64. It does work, however, on aarch64,

[Qemu-devel] [Bug 1705118] Re: qemu user mode does not support catching SIGSEGV on some architectures

** Attachment added: "Statically compiled test program for ppc" https://bugs.launchpad.net/qemu/+bug/1705118/+attachment/4917117/+files/testsigsegv-ppc -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1705118] Re: qemu user mode does not support catching SIGSEGV on some architectures

** Attachment added: "Statically compiled test program for ppc64le" https://bugs.launchpad.net/qemu/+bug/1705118/+attachment/4917119/+files/testsigsegv-ppc64le -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1705118] Re: qemu user mode does not support catching SIGSEGV on some architectures

** Attachment added: "Statically compiled test program for sparc64" https://bugs.launchpad.net/qemu/+bug/1705118/+attachment/4917121/+files/testsigsegv-sparc64 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1705118] Re: qemu user mode does not support catching SIGSEGV on some architectures

** Attachment added: "Statically compiled test program for s390x" https://bugs.launchpad.net/qemu/+bug/1705118/+attachment/4917120/+files/testsigsegv-s390x -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1704658] Re: O_CLOEXEC not handled in dup3 system call in user mode

I see this bug for hppa, sparc64. I don't see it for m68k, mips, mips64, powerpc, powerpc64. Most likely because the binary values of O_CLOEXEC on hppa and sparc64 are different than on other platforms. Looking in the glibc source code: $ grep -r 'define.*O_CLOEXEC' glibc glibc/bits/fcntl.h:#

[Qemu-devel] [Bug 1704658] Re: O_CLOEXEC not handled in dup3 system call in user mode

** Attachment added: "Statically compiled test program for hppa" https://bugs.launchpad.net/qemu/+bug/1704658/+attachment/4915666/+files/testdup3-hppa -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1704658] [NEW] O_CLOEXEC not handled in dup3 system call in user mode

Public bug reported: In qemu user mode, for hppa and sparc64 targets, the parameter of the dup3 is not passed correctly when it contains the O_CLOEXEC flag. When the attached program runs, the expected output is: errno=9=EBADF How to reproduce on hppa: - Compile the program:

[Qemu-devel] [Bug 1704658] Re: O_CLOEXEC not handled in dup3 system call in user mode

** Attachment added: "Statically compiled test program for sparc64" https://bugs.launchpad.net/qemu/+bug/1704658/+attachment/4915667/+files/testdup3-sparc64 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1704638] [NEW] weak symbol access makes qemu in user mode hang for mips, mips64

Public bug reported: A program that is statically linked and invokes a weak pointer should crash (because the weak pointer evaluates to NULL). With qemu in user mode, for mips and mips64, it hangs. The process needs to be killed with "kill -9". How to reproduce for mips: - Compile the program:

[Qemu-devel] [Bug 1704638] Re: weak symbol access makes qemu in user mode hang for mips, mips64

** Attachment added: "Statically compiled test program for mips" https://bugs.launchpad.net/qemu/+bug/1704638/+attachment/4915584/+files/testpthsigmask-mips -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1704638] Re: weak symbol access makes qemu in user mode hang for mips, mips64

** Attachment added: "Statically compiled test program for mips64" https://bugs.launchpad.net/qemu/+bug/1704638/+attachment/4915585/+files/testpthsigmask-mips64 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1701974] [NEW] pwrite does not work right under qemu-sh4

Public bug reported: The pwrite system call has no effect when writing to a non-zero file position, in a program running under qemu-sh4 (version 2.9.0). How to reproduce: - Compile the program: sh4-linux-gnu-gcc-5 -O -Wall -static -o test-pwrite test-pwrite.c - Set environment variable for

[Qemu-devel] [Bug 1701973] Re: pread does not work right under qemu-sh4

In case it matters: My host platform is Linux/x86_64. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1701973 Title: pread does not work right under qemu-sh4 Status in QEMU: New Bug description:

[Qemu-devel] [Bug 1701974] Re: pwrite does not work right under qemu-sh4

In case it matters: My host platform is Linux/x86_64. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1701974 Title: pwrite does not work right under qemu-sh4 Status in QEMU: New Bug

[Qemu-devel] [Bug 1701974] Re: pwrite does not work right under qemu-sh4

** Attachment added: "Statically linked compiled test program" https://bugs.launchpad.net/qemu/+bug/1701974/+attachment/4908132/+files/test-pwrite -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1701973] Re: pread does not work right under qemu-sh4

** Attachment added: "Statically linked compiled test program" https://bugs.launchpad.net/qemu/+bug/1701973/+attachment/4908130/+files/test-pread -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1701973] [NEW] pread does not work right under qemu-sh4

Public bug reported: The pread system call returns a wrong value in some case, in a program running under qemu-sh4 (version 2.9.0). How to reproduce: - Compile the program: sh4-linux-gnu-gcc-5 -O -Wall -static -o test-pread test-pread.c - Set environment variable for using qemu-sh4 (actually

[Qemu-devel] [Bug 1701971] Re: multithreading not working right under qemu user mode for sh4

Another gnulib test (test-lock) fails with an assertion inside glibc: test-lock: pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. qemu: uncaught target signal 6 (Aborted) - core dumped Based on this, I would speculate that the problem is in the qemu

[Qemu-devel] [Bug 1701971] [NEW] multithreading not working right under qemu user mode for sh4

Public bug reported: In a multithreaded program running under qemu-sh4 (version 2.9.0), thread termination and/or pthread_join is not working right. The attached program works natively on all kinds of platforms, and under qemu user mode emulation for at least alpha, armelhf, aarch64,

[Qemu-devel] [Bug 1701971] Re: multithreading not working right under qemu user mode for sh4

** Attachment added: "Compiled test program" https://bugs.launchpad.net/qemu/+bug/1701971/+attachment/4908118/+files/test-tls -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1701971 Title:

Re: [Qemu-devel] [PATCH v2 0/5] target/sh4: misc FPU fixes and optimizations

Aurelien Jarno wrote: > This patchset should fix the bug#1701821 reported by Bruno Haible, > which makes the gnulib testsuite to fail for single precision libm > tests or for tests relying on unordered comparisons. It does fix it: All floating-point related tests of gnulib now pass with

Re: [Qemu-devel] [PATCH 0/2] target/sh4: fix fabs and optimize fneg

Hi Aurelien, > This patchset should fix the bug #1701821 reported by Bruno Haible, > which makes the gnulib testsuite to fail for single precision libm > tests. > > Aurelien Jarno (2): > target/sh4: do not check for PR bit for fabs instruction > target/sh4: do not use

[Qemu-devel] [Bug 1701835] [NEW] floating-point operation bugs in qemu-alpha

Public bug reported: When running the gnulib testsuite, I'm seeing test failures in the tests for libm functions cbrt cbrtf ceil ceilf coshf exp2 exp2f floor floorf fma fmaf fmal frexp frexpf hypot hypotf hypotl ilogb ilogbf isfinite isinf isnan

[Qemu-devel] [Bug 1701821] [NEW] floating-point operation bugs in qemu-sh4

Public bug reported: When running the gnulib testsuite, I'm seeing test failures in the tests for libm functions asinf cbrtf copysignf coshf expm1f fabsf floor fmaf ldexpf logbf round roundf sinhf tanhf How to reproduce: - Using gnulib, run ./gnulib-tool

[Qemu-devel] [Bug 1701808] [NEW] stack smashing in or after recvmsg system call in aarch64 user mode

Public bug reported: A program that invokes recvmsg aborts with "*** stack smashing detected ***" when run in qemu-aarch64 (user mode), but works fine when running on native aarch64 hardware. How to reproduce: $ aarch64-linux-gnu-gcc-5 -O -Wall /media/develdata/devel/qemu-bug/testpassfd.c

[Qemu-devel] [Bug 1701808] Re: stack smashing in or after recvmsg system call in aarch64 user mode

** Attachment added: "Statically compiled test program" https://bugs.launchpad.net/qemu/+bug/1701808/+attachment/4907340/+files/a.out -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1701808 Title:

[Qemu-devel] [Bug 1701798] Re: dynamically linked binaries crash for big-endian targets

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.

[Qemu-devel] [Bug 1701798] [NEW] dynamically linked binaries crash for big-endian targets

Public bug reported: On the targets hppa m68k mips mips64 powerpc powerpc64 s390x sparc64 dynamically linked binaries crash, but statically linked binaries work. On the targets aarch64 alpha armhf powerpc64le sh4 both dynamically linked and statically linked binaries

[Qemu-devel] [Bug 1701808] Re: stack smashing in or after recvmsg system call in aarch64 user mode

Likewise for 32-bit arm: $ ~/inst-qemu/2.9.0/bin/qemu-arm ./a.arm *** stack smashing detected ***: ./a.arm terminated qemu: uncaught target signal 6 (Aborted) - core dumped ** Attachment added: "Statically compiled test program for arm"