Re: [PATCH RFC] hw/sh4/sh7750: Add STBCR/STBCR2 register support
Hi Geert! On Wed, 2023-10-18 at 14:40 +0200, Geert Uytterhoeven wrote: > The new Linux SH7750 clock driver uses the registers for power-down > mode control, causing a crash: > > byte read to SH7750_STBCR_A7 (0x1fc4) not supported > Aborted (core dumped) > > Fix this by adding support for the Standby Control Registers STBCR and > STBCR2. > > Signed-off-by: Geert Uytterhoeven Is this supposed to be applied on top of Yoshinori's DT conversion series? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PULL 1/6] linux-user/sparc: Don't use 16-bit UIDs on SPARC V9
Hello Laurent! On Fri, 2023-05-12 at 13:13 +0200, Laurent Vivier wrote: > This patch breaks something with LTP (20230127) test fchown05_16 on > sid/sparc64: > > tst_test.c:1558: TINFO: Timeout per run is 0h 00m 30s > fchown05.c:44: TPASS: fchown(3, 700, 701), change owner/group ids passed > fchown05.c:44: TPASS: fchown(3, 702, -1), change owner id only passed > fchown05.c:49: TFAIL: testfile: incorrect ownership set, expected 702 701 > fchown05.c:44: TPASS: fchown(3, 703, 701), change owner id only passed > fchown05.c:44: TPASS: fchown(3, -1, 704), change group id only passed > fchown05.c:49: TFAIL: testfile: incorrect ownership set, expected 703 704 > fchown05.c:44: TPASS: fchown(3, 703, 705), change group id only passed > fchown05.c:44: TPASS: fchown(3, -1, -1), no change passed > fchown05.c:49: TFAIL: testfile: incorrect ownership set, expected 703 705 > > expected result; > > tst_test.c:1558: TINFO: Timeout per run is 0h 00m 30s > fchown05.c:44: TPASS: fchown(3, 700, 701), change owner/group ids passed > fchown05.c:44: TPASS: fchown(3, 702, -1), change owner id only passed > fchown05.c:44: TPASS: fchown(3, 703, 701), change owner id only passed > fchown05.c:44: TPASS: fchown(3, -1, 704), change group id only passed > fchown05.c:44: TPASS: fchown(3, 703, 705), change group id only passed > fchown05.c:44: TPASS: fchown(3, -1, -1), no change passed Where do these tests reside? I'm not sure I know what LTP is. In any case, the patch should be correct as QEMU needs to differentiate between 32-bit and 64-bit SPARC. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2 0/6] Deprecate support for 32-bit x86 and arm hosts
Hi Thomas! On Fri, 2023-03-03 at 12:22 +0100, Thomas Huth wrote: > The ticket is very long and hard to read, but ... oh my, does that mean you > need to compile qemu-user in 32-bit mode on a 64-bit x86 host to properly > run 32-bit binaries from other architectures? ... uh, that's ugly ... and > sounds like bug in QEMU's user mode emulation ... and what if you're running > a distro (or different 64-bit host architecutre) that does not support > 32-bit userspace libraries anymore? Then you're lost? Perhaps the explanation here by Florian Weimer is a bit easier to understand: > https://lore.kernel.org/lkml/87bm56vqg4@mid.deneb.enyo.de/ Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2 0/6] Deprecate support for 32-bit x86 and arm hosts
Hello! On Fri, 2023-03-03 at 10:48 +0100, Thomas Huth wrote: > x86 ==> deprecate both, user and system emulation support on > 32-bit hosts > arm ==> deprecate only system emulation on 32-bit hosts. I would recommend against dropping support for 32-bit hosts for qemu-user as there are some cases where the emulation of 32-bit user code on 64-bit hosts does not work properly [1]. Adrian > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=23960 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Byte-swapping issue on qemu-user for sparc64 guest
Hi Thomas! On Fri, 2023-02-10 at 16:52 +0100, Thomas Huth wrote: > On 10/02/2023 16.23, John Paul Adrian Glaubitz wrote: > > Hi! > > > > There is an unaddressed issue in qemu-user [1] which results in getresuid() > > returning an incorrect UID due to a byte-swapping issue on sparc64. > > Oh, there are still people out there using qemu-user on sparc64 hosts? ... This is about running sparc64 binaries on x86_64. > that reminds me of another outstanding issue which might occur there: > > https://mail.gnu.org/archive/html/qemu-devel/2021-02/msg04240.html > > ... in case someone has time for fixing this ... (I unfortunately never > found enough spare time again to revisit the issue). We're still maintaining a sparc64 port in Debian, FWIW. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Byte-swapping issue on qemu-user for sparc64 guest
Hi! There is an unaddressed issue in qemu-user [1] which results in getresuid() returning an incorrect UID due to a byte-swapping issue on sparc64. This issue is fixed by the patch below which was suggested by Phillippe Mathieu-Daudé, but the corresponding line [2] has not been patched yet. Could anyone step up and fix the bug? Thanks, Adrian diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h index 77864de57f..4d4b4a22e8 100644 --- a/linux-user/syscall_defs.h +++ b/linux-user/syscall_defs.h @@ -61,7 +61,7 @@ #if (defined(TARGET_I386) && defined(TARGET_ABI32)) \ || (defined(TARGET_ARM) && defined(TARGET_ABI32)) \ - || defined(TARGET_SPARC) \ + || (defined(TARGET_SPARC) && defined(TARGET_ABI32)) \ || defined(TARGET_M68K) || defined(TARGET_SH4) || defined(TARGET_CRIS) /* 16 bit uid wrappers emulation */ #define USE_UID16 > [1] https://gitlab.com/qemu-project/qemu/-/issues/1394 > [2] > https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall_defs.h#L64 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Linker failures trying to build static qemu-user binary
On Thu, 2023-02-09 at 14:23 +, Peter Maydell wrote: > > So, just include "-ldl" in LD_FLAGS? > > If this is necessary, then pkg-config should tell us to do it :-) > > But in the usual situation that you put the statically linked > QEMU binary into a chroot, the dlopen() that libdw is going to > try to do won't work anyway... FWIW, passing --extra-ldflags="-ldl" fixes the issue for me. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Linker failures trying to build static qemu-user binary
Hi! On Thu, 2023-02-09 at 14:14 +, Peter Maydell wrote: > The "Using getpwuid in statically linked applications" etc warnings > are expected, so we can ignore those; this is the key error: OK. > > /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libdw.a(debuginfod-client.o): in > > function `__libdwfl_debuginfod_init': > > (.text.startup+0x17): undefined reference to `dlopen' > > /usr/bin/ld: (.text.startup+0x32): undefined reference to `dlsym' > > /usr/bin/ld: (.text.startup+0x4b): undefined reference to `dlsym' > > /usr/bin/ld: (.text.startup+0x64): undefined reference to `dlsym' > > /usr/bin/ld: (.text.startup+0x7d): undefined reference to `dlsym' > > /usr/bin/ld: (.text.startup+0xdc): undefined reference to `dlclose' > > collect2: error: ld returned 1 exit status > > We use pkg-config to find out what the libdw library needs on > the compiler/linker command line to link successfully, so > maybe your distro's pkg-config info isn't right. What does > "pkg-config --static --libs libdw" say ? glaubitz@nofan:~> pkg-config --static --libs libdw -ldw -lbz2 -llzma -pthread -lpthread -lelf -lz glaubitz@nofan:~> I'm building on Debian stable (Bullseye). > If libdw needs libdl > then it ought to list it in that output, I think. IME pkg-config > information is often incorrect for static linking, though. > I guess this one happened to work previously because glibc didn't > actually mandate linking with '-ldl', and now on your system it > apparently does. On my system pkg-config says > -ldw -lbz2 -llzma -pthread -lpthread -lelf -lz > which looks like it's missing -ldl, but the link succeeds anyway, > presumably because the symbols are provided by the main glibc .a. > > On the other hand, if libdw wants to use dlopen/dlsym then > I wonder if we should just suppress it for static linking: > on my (Ubuntu 22.04) ld warns: > /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libdw.a(debuginfod-client.o): > in function `__libdwfl_debuginfod_init': > (.text.startup+0x1b): warning: Using 'dlopen' in statically linked > applications requires at runtime the shared libraries from the glibc > version used for linking > > so whatever libdw is trying to do will likely not work in most > statically-linked situations anyway. So, just include "-ldl" in LD_FLAGS? > I've cc'd the author of the commit that added the libdw > dependency. Thank you! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Linker failures trying to build static qemu-user binary
ser.fa.p/linux-user_main.c.o libqemu-m68k-linux-user.fa.p/linux- user_mmap.c.o libqemu-m68k-linux-user.fa.p/linux-user_signal.c.o libqemu-m68k-linux-user.fa.p/linux-user_strace.c.o libqemu-m68k-linux- user.fa.p/linux-user_syscall.c.o libqemu-m68k-linux-user.fa.p/linux-user_thunk.c.o libqemu-m68k-linux-user.fa.p/linux-user_uaccess.c.o libqemu-m68k-linux-user.fa.p/linux-user_uname.c.o libqemu-m68k-linux-user.fa.p/linux-user_flatload.c.o libqemu-m68k-linux-user.fa.p/meson- generated_.._m68k-linux-user-gdbstub-xml.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,--whole-archive libhwcore.fa libqom.fa -Wl,--start-group libevent-loop-base.a -Wl,--no-whole-archive -fstack-protector-strong -static -Wl,-z,relro -Wl,-z,now -Wl,--warn-common libqemuutil.a libhwcore.fa libqom.fa /usr/lib/x86_64-linux-gnu/libcapstone.a /usr/lib/x86_64-linux-gnu/libdw.a /usr/lib/x86_64-linux-gnu/libbz2.a /usr/lib/x86_64-linux-gnu/liblzma.a -pthread -lpthread /usr/lib/x86_64-linux-gnu/libelf.a /usr/lib/x86_64-linux-gnu/libz.a -lrt -lm - lgthread-2.0 -lglib-2.0 -lpcre -lstdc++ -Wl,--end-group /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libglib-2.0.a(gutils.c.o): in function `g_get_user_database_entry': (.text+0x277): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/bin/ld: (.text+0xe0): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/bin/ld: (.text+0x11e): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libdw.a(debuginfod-client.o): in function `__libdwfl_debuginfod_init': (.text.startup+0x17): undefined reference to `dlopen' /usr/bin/ld: (.text.startup+0x32): undefined reference to `dlsym' /usr/bin/ld: (.text.startup+0x4b): undefined reference to `dlsym' /usr/bin/ld: (.text.startup+0x64): undefined reference to `dlsym' /usr/bin/ld: (.text.startup+0x7d): undefined reference to `dlsym' /usr/bin/ld: (.text.startup+0xdc): undefined reference to `dlclose' collect2: error: ld returned 1 exit status [843/934] Linking target tests/unit/check-qdict /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libglib-2.0.a(gutils.c.o): in function `g_get_user_database_entry': (.text+0x277): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/bin/ld: (.text+0xe0): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/bin/ld: (.text+0x11e): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking [844/934] Linking target tests/unit/check-qnum /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libglib-2.0.a(gutils.c.o): in function `g_get_user_database_entry': (.text+0x277): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/bin/ld: (.text+0xe0): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/bin/ld: (.text+0x11e): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking [845/934] Compiling C object tests/unit/check-qlist.p/check-qlist.c.o [846/934] Compiling C object tests/fp/fp-test.p/.._.._fpu_softfloat.c.o [847/934] Compiling C object tests/fp/fp-bench.p/.._.._fpu_softfloat.c.o [848/934] Compiling C object tests/fp/fp-test-log2.p/.._.._fpu_softfloat.c.o [849/934] Generating docs/QEMU manual with a custom command ninja: build stopped: subcommand failed. make[1]: *** [Makefile:165: run-ninja] Error 1 make[1]: Leaving directory '/root/qemu/build' make: *** [GNUmakefile:11: all] Error 2q -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Looking for advise on debugging a non-boot kernel on qemu-system-sh4
Hi Zoltan! On 10/26/21 00:40, BALATON Zoltan wrote: > On Tue, 26 Oct 2021, John Paul Adrian Glaubitz wrote: >> Hi Zoltan! >> >> On 10/23/21 15:22, BALATON Zoltan wrote: >>>> You either need to strip the kernel with "strip vmlinux" or use the image >>>> from arch/sh/ >>>> boot/zImage. >>> >>> I've actually used that kernel but looked at the wrong uncompressed size, >>> it's indeed just >>> 9.2MB when stripped so that should work. I was trying to debug further and >>> found two problems: >>> >>> Commit abb0cd93494 (accel/tcg: Split out log_cpu_exec) seems to have broken >>> -singlestep -d in_asm,cpu >>> output with sh after a delay slot. Since that commit I get: >>> (...) >>> This seems to take a wrong turn at the delayed branch and somehow ends up >>> at 0x8c800964 instead of >>> 0x8c801528 but I'm not sure where to look firther why. I'm cc-ing Richard >>> for both the -d cpu and >>> this hoping he has some more insight. >> >> Shall we open a bug report? > > Well, we don't know yet what to put in the bug report apart from there is > some bug somewhere. That's > not too useful. I now understand that the -d output is not showing already > translated TBs (I knew this > but most of the time with -singlestep it gives good results anyway) but here > it runs the loops without > further output then we only see the first loop iteration and the end result. > So the problem is not that > it goes to 0x8c800964 as I think that's part of the loop for decompressing > the kernel but it seems > something is overwriting 0x8c800964 while it still expects to run code from > there but I don't know what > and why. One way to find could be to disassemble the kernel code and compare > that with the -d output and > check every instruction manually but that takes a lot of time or if you have > a cross debugger you could > try attaching that to QEMU and try to debug it that way but I don't have that > either. Any other idea how > to find out what is happening? Robert Święcki (CC'ed) found out that disabling tracing support makes Debian's kernel bootable [1]. Not sure if this is a kernel bug or a QEMU bug then. Does QEMU have any support for kernel tracing? Adrian > [1] https://marc.info/?l=linux-sh=164193147916418=2 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Looking for advise on debugging a non-boot kernel on qemu-system-sh4
Hi Zoltan! On 10/23/21 15:22, BALATON Zoltan wrote: >> You either need to strip the kernel with "strip vmlinux" or use the image >> from arch/sh/ >> boot/zImage. > > I've actually used that kernel but looked at the wrong uncompressed size, > it's indeed just > 9.2MB when stripped so that should work. I was trying to debug further and > found two problems: > > Commit abb0cd93494 (accel/tcg: Split out log_cpu_exec) seems to have broken > -singlestep -d in_asm,cpu > output with sh after a delay slot. Since that commit I get: > (...) > This seems to take a wrong turn at the delayed branch and somehow ends up at > 0x8c800964 instead of > 0x8c801528 but I'm not sure where to look firther why. I'm cc-ing Richard for > both the -d cpu and > this hoping he has some more insight. Shall we open a bug report? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Looking for advise on debugging a non-boot kernel on qemu-system-sh4
Hello Zoltan! On 10/23/21 03:07, BALATON Zoltan wrote: >> I can confirm that the default config works for me, too. Both with gcc-8 and >> gcc-11. > > OK with your config I can reproduce the problem too but the kernel with that > config > is 177MB and the r2d board has 64MB RAM so this can't work that way. Then > it's likely > not a but but a too big kernel. You either need to strip the kernel with "strip vmlinux" or use the image from arch/sh/ boot/zImage. >> Using that kernel, however, I cannot use the debian-installer initrd.gz, >> even with >> CONFIG_BLK_DEV_INITRD enabled in the kernel configuration. >> >> The kernel prints a message saying that the initramfs is uncompressed, but >> whatever I >> do I cannot get it to mount the initramfs. All I get is this: >> >> [0.096000] Trying to unpack rootfs image as initramfs... >> >> and then later: >> >> [0.48] ---[ end trace 46a3adcb34136251 ]--- >> [0.48] Kernel panic - not syncing: Attempted to kill init! >> exitcode=0x000b >> [0.48] ---[ end Kernel panic - not syncing: Attempted to kill init! >> exitcode=0x000b ]--- > > I don't know, you have to find the needed config options to have what's > needed to use this initrd. > You could either try to strip down the debian config or add more to the > default until you get a > working kernel that fits in the memory (and there's some left to run other > processes). I'll keep digging. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Looking for advise on debugging a non-boot kernel on qemu-system-sh4
Hi Zoltan! On 10/22/21 23:49, John Paul Adrian Glaubitz wrote: >> How did you compile the kernel that does not boot? What config have you used? > > The config is constructed from the Debian kernel configuration tree. I have > uploaded > the resulting config file here: > >> https://people.debian.org/~glaubitz/config-5.14.0-3-sh7751r.gz > >> I've tried to reproduce it by compiling a kernel with rts7751r2d1_defconfig >> and different >> compression methods but it did start and never got the problem seen with >> your kernel. > > Oh, that's very interesting. How big were the kernel images you got? My > suspicion was > that the current Debian kernel might be too much. I can confirm that the default config works for me, too. Both with gcc-8 and gcc-11. Using that kernel, however, I cannot use the debian-installer initrd.gz, even with CONFIG_BLK_DEV_INITRD enabled in the kernel configuration. The kernel prints a message saying that the initramfs is uncompressed, but whatever I do I cannot get it to mount the initramfs. All I get is this: [0.096000] Trying to unpack rootfs image as initramfs... and then later: [0.48] ---[ end trace 46a3adcb34136251 ]--- [0.48] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b [0.48] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b ]--- Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Looking for advise on debugging a non-boot kernel on qemu-system-sh4
Hi Zoltan! Thanks a lot for helping me to investigate the problem. Much appreciated! On 10/22/21 23:06, BALATON Zoltan wrote: >> I think I've seen problems with compressed kernel images and QEMU before. I >> will switch >> to an uncompressed kernel and try again. > > How did you compile the kernel that does not boot? What config have you used? The config is constructed from the Debian kernel configuration tree. I have uploaded the resulting config file here: > https://people.debian.org/~glaubitz/config-5.14.0-3-sh7751r.gz I've tried to reproduce it by compiling a kernel with rts7751r2d1_defconfig and different > compression methods but it did start and never got the problem seen with your > kernel. Oh, that's very interesting. How big were the kernel images you got? My suspicion was that the current Debian kernel might be too much. > Maybe it's the gcc version? My cross compiler is 8.4.0 and you seem to use > 10.x. Maybe > newer gcc uses something that's not emulated correctly? Yes, it has been built with gcc-10 which is currently Debian's default kernel for building the kernel. > It would be interesting to identify what's causing the problem. Indeed. Thanks for helping me with that. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Looking for advise on debugging a non-boot kernel on qemu-system-sh4
Hi Zoltan! On 10/21/21 15:49, BALATON Zoltan wrote: > So somthing seems to overwrite it. Maybe you can try building an uncompressed > kernel or one using a different compression and see if that does the same, at > least that way we can see if it's in the decompressing or later. I think it's > past linux/arch/sh/boot/compressed/head32.S and maybe somewhere in > decompress_kernel > but not sure which decompression it uses. Kernel config is also missing to > check > but I probably give up at this point and let you experiment some more. I think I've seen problems with compressed kernel images and QEMU before. I will switch to an uncompressed kernel and try again. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Looking for advise on debugging a non-boot kernel on qemu-system-sh4
Hi Zoltan! On 10/21/21 14:12, BALATON Zoltan wrote: > Adding -d in_asm shows it seems to loop early in the kernel but not sure > where. > Maybe try to compare addresses with System.map to find out where it's getting > stuck (but System.map was not included in your installer image). Here is the System.map if that helps [1]. > Also if it works on earlier kernel you might try to bisect which kernel commit > caused the problem. Maybe knowing that helps to tell where to look further. If nothing else helps, I will try that. Adrian > [1] https://people.debian.org/~glaubitz/System.map-5.14.0-3-sh7751r.gz -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Looking for advise on debugging a non-boot kernel on qemu-system-sh4
Hello! I'm regularly building debian-installer packages for Debian's unofficial ports which includes sh4 among others. The kernel package and therefore the installer package contains a kernel for the SH7751R machine which is emulated by QEMU when choosing the "r2d" type. Unfortunately, I have not yet been able to boot a current kernel on qemu-system-sh4, the screen remains blank and there are no error messages. Booting an older 2.6 kernel works just fine. I'm using qemu-system-sh4 as follows: $ qemu-system-sh4 -M r2d -kernel vmlinuz-2.6.32-5-sh7751r -initrd initrd.gz -hda debian.img \ -append "root=/dev/sda1 console=tty0 noiotrap" The old 2.6 kernel from [1] boots fine while the current 5.14.x kernel from [2] does not produce any output. Can anyone enlighten me what I might be missing? Thanks, Adrian PS: Please CC me as I am subscribed without getting messages. > [1] https://people.debian.org/~aurel32/qemu/sh4/ > [2] https://cdimage.debian.org/cdimage/ports/current-debian-installer/sh4/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[Bug 1796520] Re: autogen crashes on qemu-sh4-user after 61dedf2af7
Yes, it can be closed. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1796520 Title: autogen crashes on qemu-sh4-user after 61dedf2af7 Status in QEMU: Incomplete Bug description: Running "autogen --help" crashes on qemu-sh4-user with: (sid-sh4-sbuild)root@nofan:/# autogen --help Unhandled trap: 0x180 pc=0xf64dd2de sr=0x pr=0xf63b9c74 fpscr=0x0008 spc=0x ssr=0x gbr=0xf61102a8 vbr=0x sgr=0x dbr=0x delayed_pc=0xf64dd2a0 fpul=0x0003 r0=0xf6fc1320 r1=0x r2=0x5dc4 r3=0xf67bfb50 r4=0xf6fc1230 r5=0xf6fc141c r6=0x03ff r7=0x r8=0x0004 r9=0xf63e20bc r10=0xf6fc141c r11=0xf63e28f0 r12=0xf63e2258 r13=0xf63eae1c r14=0x0804 r15=0xf6fc1220 r16=0x r17=0x r18=0x r19=0x r20=0x r21=0x r22=0x r23=0x (sid-sh4-sbuild)root@nofan:/# Bi-secting found this commit to be the culprit: 61dedf2af79fb5866dc7a0f972093682f2185e17 is the first bad commit commit 61dedf2af79fb5866dc7a0f972093682f2185e17 Author: Richard Henderson Date: Tue Jul 18 10:02:50 2017 -1000 target/sh4: Add missing FPSCR.PR == 0 checks Both frchg and fschg require PR == 0, otherwise undefined_operation. Reviewed-by: Aurelien Jarno Signed-off-by: Richard Henderson Message-Id: <20170718200255.31647-26-...@twiddle.net> Signed-off-by: Aurelien Jarno :04 04 980d79b69ae712f23a1e4c56983e97a843153b4a 1024c109f506c7ad57367c63bc8bbbc8a7a36cd7 M target Reverting 61dedf2af79fb5866dc7a0f972093682f2185e17 fixes the problem for me. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1796520/+subscriptions
[Bug 1796520] Re: autogen crashes on qemu-sh4-user after 61dedf2af7
The patch suggested by Thorsten Glaser glibc Bugzilla #27543 fixes the issue for me: > https://sourceware.org/bugzilla/show_bug.cgi?id=27543#c2 ** Bug watch added: Sourceware.org Bugzilla #27543 https://sourceware.org/bugzilla/show_bug.cgi?id=27543 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1796520 Title: autogen crashes on qemu-sh4-user after 61dedf2af7 Status in QEMU: Incomplete Bug description: Running "autogen --help" crashes on qemu-sh4-user with: (sid-sh4-sbuild)root@nofan:/# autogen --help Unhandled trap: 0x180 pc=0xf64dd2de sr=0x pr=0xf63b9c74 fpscr=0x0008 spc=0x ssr=0x gbr=0xf61102a8 vbr=0x sgr=0x dbr=0x delayed_pc=0xf64dd2a0 fpul=0x0003 r0=0xf6fc1320 r1=0x r2=0x5dc4 r3=0xf67bfb50 r4=0xf6fc1230 r5=0xf6fc141c r6=0x03ff r7=0x r8=0x0004 r9=0xf63e20bc r10=0xf6fc141c r11=0xf63e28f0 r12=0xf63e2258 r13=0xf63eae1c r14=0x0804 r15=0xf6fc1220 r16=0x r17=0x r18=0x r19=0x r20=0x r21=0x r22=0x r23=0x (sid-sh4-sbuild)root@nofan:/# Bi-secting found this commit to be the culprit: 61dedf2af79fb5866dc7a0f972093682f2185e17 is the first bad commit commit 61dedf2af79fb5866dc7a0f972093682f2185e17 Author: Richard Henderson Date: Tue Jul 18 10:02:50 2017 -1000 target/sh4: Add missing FPSCR.PR == 0 checks Both frchg and fschg require PR == 0, otherwise undefined_operation. Reviewed-by: Aurelien Jarno Signed-off-by: Richard Henderson Message-Id: <20170718200255.31647-26-...@twiddle.net> Signed-off-by: Aurelien Jarno :04 04 980d79b69ae712f23a1e4c56983e97a843153b4a 1024c109f506c7ad57367c63bc8bbbc8a7a36cd7 M target Reverting 61dedf2af79fb5866dc7a0f972093682f2185e17 fixes the problem for me. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1796520/+subscriptions
[Bug 1836763] Re: Firebird crashes on qemu-m68k-user with pthread_mutex_init error
** Changed in: qemu Status: Expired => New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1836763 Title: Firebird crashes on qemu-m68k-user with pthread_mutex_init error Status in QEMU: New Bug description: Trying to use the Firebird database on qemu-m68k-user with a Debian chroot fails with the database crashing with "ConfigStorage: mutex pthread_mutex_init error, status = 95": (sid-m68k-sbuild)root@epyc:/# apt install firebird3.0-server Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: cpio libip4tc0 Use 'apt autoremove' to remove them. The following additional packages will be installed: firebird3.0-common firebird3.0-common-doc firebird3.0-server-core firebird3.0-utils libfbclient2 libib-util Suggested packages: firebird3.0-doc The following NEW packages will be installed: firebird3.0-common firebird3.0-common-doc firebird3.0-server firebird3.0-server-core firebird3.0-utils libfbclient2 libib-util 0 upgraded, 7 newly installed, 0 to remove and 4 not upgraded. Need to get 4,051 kB of archives. After this operation, 15.9 MB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-common-doc all 3.0.5.33100.ds4-3 [35.3 kB] Get:2 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-common all 3.0.5.33100.ds4-3 [14.5 kB] Get:3 http://ftp.ports.debian.org/debian-ports unstable/main m68k libfbclient2 m68k 3.0.5.33100.ds4-3 [496 kB] Get:4 http://ftp.ports.debian.org/debian-ports unstable/main m68k libib-util m68k 3.0.5.33100.ds4-3 [3,220 B] Get:5 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-server-core m68k 3.0.5.33100.ds4-3 [2,368 kB] Get:6 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-utils m68k 3.0.5.33100.ds4-3 [770 kB] Get:7 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-server m68k 3.0.5.33100.ds4-3 [365 kB] Fetched 4,051 kB in 2s (1,803 kB/s) debconf: delaying package configuration, since apt-utils is not installed E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device) Selecting previously unselected package firebird3.0-common-doc. (Reading database ... 33605 files and directories currently installed.) Preparing to unpack .../0-firebird3.0-common-doc_3.0.5.33100.ds4-3_all.deb ... Unpacking firebird3.0-common-doc (3.0.5.33100.ds4-3) ... Selecting previously unselected package firebird3.0-common. Preparing to unpack .../1-firebird3.0-common_3.0.5.33100.ds4-3_all.deb ... Unpacking firebird3.0-common (3.0.5.33100.ds4-3) ... Selecting previously unselected package libfbclient2:m68k. Preparing to unpack .../2-libfbclient2_3.0.5.33100.ds4-3_m68k.deb ... Unpacking libfbclient2:m68k (3.0.5.33100.ds4-3) ... Selecting previously unselected package libib-util:m68k. Preparing to unpack .../3-libib-util_3.0.5.33100.ds4-3_m68k.deb ... Unpacking libib-util:m68k (3.0.5.33100.ds4-3) ... Selecting previously unselected package firebird3.0-server-core:m68k. Preparing to unpack .../4-firebird3.0-server-core_3.0.5.33100.ds4-3_m68k.deb ... Unpacking firebird3.0-server-core:m68k (3.0.5.33100.ds4-3) ... Selecting previously unselected package firebird3.0-utils. Preparing to unpack .../5-firebird3.0-utils_3.0.5.33100.ds4-3_m68k.deb ... Unpacking firebird3.0-utils (3.0.5.33100.ds4-3) ... Selecting previously unselected package firebird3.0-server. Preparing to unpack .../6-firebird3.0-server_3.0.5.33100.ds4-3_m68k.deb ... Unpacking firebird3.0-server (3.0.5.33100.ds4-3) ... Setting up firebird3.0-common-doc (3.0.5.33100.ds4-3) ... Setting up firebird3.0-common (3.0.5.33100.ds4-3) ... Setting up libib-util:m68k (3.0.5.33100.ds4-3) ... Setting up libfbclient2:m68k (3.0.5.33100.ds4-3) ... Setting up firebird3.0-utils (3.0.5.33100.ds4-3) ... Setting up firebird3.0-server-core:m68k (3.0.5.33100.ds4-3) ... Setting up firebird3.0-server (3.0.5.33100.ds4-3) ... debconf: unable to initialize frontend: Dialog debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.) debconf: falling back to frontend: Readline Password for firebird 3.0 - Firebird has a special user named SYSDBA, which is the user that has access to all databases. SYSDBA can also create new databases and users. Because of this, it is necessary to secure SYSDBA with a password. The password is stored in /etc/firebird/3.0/SYSDBA.password (readable only by root). You may modify it there (don't forget to update the security database too, using
[Bug 1796520] Re: autogen crashes on qemu-sh4-user after 61dedf2af7
Reported as https://sourceware.org/bugzilla/show_bug.cgi?id=27543 ** Bug watch added: Sourceware.org Bugzilla #27543 https://sourceware.org/bugzilla/show_bug.cgi?id=27543 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1796520 Title: autogen crashes on qemu-sh4-user after 61dedf2af7 Status in QEMU: Incomplete Bug description: Running "autogen --help" crashes on qemu-sh4-user with: (sid-sh4-sbuild)root@nofan:/# autogen --help Unhandled trap: 0x180 pc=0xf64dd2de sr=0x pr=0xf63b9c74 fpscr=0x0008 spc=0x ssr=0x gbr=0xf61102a8 vbr=0x sgr=0x dbr=0x delayed_pc=0xf64dd2a0 fpul=0x0003 r0=0xf6fc1320 r1=0x r2=0x5dc4 r3=0xf67bfb50 r4=0xf6fc1230 r5=0xf6fc141c r6=0x03ff r7=0x r8=0x0004 r9=0xf63e20bc r10=0xf6fc141c r11=0xf63e28f0 r12=0xf63e2258 r13=0xf63eae1c r14=0x0804 r15=0xf6fc1220 r16=0x r17=0x r18=0x r19=0x r20=0x r21=0x r22=0x r23=0x (sid-sh4-sbuild)root@nofan:/# Bi-secting found this commit to be the culprit: 61dedf2af79fb5866dc7a0f972093682f2185e17 is the first bad commit commit 61dedf2af79fb5866dc7a0f972093682f2185e17 Author: Richard Henderson Date: Tue Jul 18 10:02:50 2017 -1000 target/sh4: Add missing FPSCR.PR == 0 checks Both frchg and fschg require PR == 0, otherwise undefined_operation. Reviewed-by: Aurelien Jarno Signed-off-by: Richard Henderson Message-Id: <20170718200255.31647-26-...@twiddle.net> Signed-off-by: Aurelien Jarno :04 04 980d79b69ae712f23a1e4c56983e97a843153b4a 1024c109f506c7ad57367c63bc8bbbc8a7a36cd7 M target Reverting 61dedf2af79fb5866dc7a0f972093682f2185e17 fixes the problem for me. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1796520/+subscriptions
Re: [PATCH] linux-user: manage binfmt-misc preserve-arg[0] flag
On 3/1/21 12:16 PM, Michael Tokarev wrote: > Oh. You tried to use qemu-user, not qemu-user-static.. > Well. I tried both packages. I also tried systemd-binfmt and binfmt-support, neither worked. > This is all about how qemu-user works, be it debian or > any other distribution, - it is basically the same. > I can only guess the wiki page you mentioned is wrong > here. There isn't really much in the wiki besides installing qemu-user-static. I was, however, able to fix it by recreating the chroot. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] linux-user: manage binfmt-misc preserve-arg[0] flag
On 3/1/21 11:40 AM, Michael Tokarev wrote: > 01.03.2021 13:35, John Paul Adrian Glaubitz wrote: > .. >> I have been trying to get qemu-user working with sbuild as it is shipped in >> Debian >> unstable now but I didn't have any success. >> >> Do you have some instructions somewhere how to get qemu-user working with >> sbuild? > > Have you seen #983087 which I fixed yesterday? Thanks, but it doesn't help, unfortunately. Do I need to use qemu-user-static or qemu-user-binfmt? -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] linux-user: manage binfmt-misc preserve-arg[0] flag
Hi Michael! On 2/22/21 3:58 PM, Michael Tokarev wrote: > 22.02.2021 17:54, John Paul Adrian Glaubitz wrote: > >> OK, gotcha. Is it supposed to work with systemd-binfmt? It looks like it >> depends >> on the old binfmt-support package. > > the qemu 4-line patch does not depend on any particular system, it relies on a > special name of its own argv[0] when registering the binfmt entry. In order > to > utilize it, we create a special-named symlink to qemu-foo and register that > one > with the binfmt-misc subsystem, no matter if it is systemd or binfmt-support > or > whatever else. I have been trying to get qemu-user working with sbuild as it is shipped in Debian unstable now but I didn't have any success. Do you have some instructions somewhere how to get qemu-user working with sbuild? My standard method [1] no longer works with the qemu-user-static package that is shipped in unstable now: > E: 15binfmt: update-binfmts: unable to open > /var/run/schroot/mount/sid-m68k-sbuild-b1484996-cb57-436b-b491-60665add9bb8/bin/sh: > No such file or directory > E: Failed to execute “/usr/bin/getent”: No such file or directory > E: Failed to execute “/usr/sbin/groupadd”: No such file or directory > E: Failed to create group sbuild Adrian > [1] https://wiki.debian.org/M68k/sbuildQEMU -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] linux-user: manage binfmt-misc preserve-arg[0] flag
On 2/22/21 3:58 PM, Michael Tokarev wrote: > 22.02.2021 17:54, John Paul Adrian Glaubitz wrote: > >> OK, gotcha. Is it supposed to work with systemd-binfmt? It looks like it >> depends >> on the old binfmt-support package. > > the qemu 4-line patch does not depend on any particular system, it relies on a > special name of its own argv[0] when registering the binfmt entry. In order > to > utilize it, we create a special-named symlink to qemu-foo and register that > one > with the binfmt-misc subsystem, no matter if it is systemd or binfmt-support > or > whatever else. OK, I was wondering this because qemu-user-static still pulls in the binfmt-support package: root@epyc:~> apt install qemu-user-static Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: binfmt-support The following NEW packages will be installed: binfmt-support qemu-user-static 0 upgraded, 2 newly installed, 0 to remove and 2 not upgraded. Other distributions such as Fedora have already switched to systemd-binfmt. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] linux-user: manage binfmt-misc preserve-arg[0] flag
On 2/22/21 3:46 PM, Michael Tokarev wrote: > 22.02.2021 17:43, John Paul Adrian Glaubitz wrote: >> On 2/22/21 3:38 PM, Michael Tokarev wrote: > >>> >>> It's been fixed a week or so ago. >> >> Doesn't the patch require a kernel fix which is only present in Linux 5.12? > > No it does not. My approach does not require kernel support but it relies > on special argv[0] for the qemu binfmt interpreter. OK, gotcha. Is it supposed to work with systemd-binfmt? It looks like it depends on the old binfmt-support package. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] linux-user: manage binfmt-misc preserve-arg[0] flag
On 2/22/21 3:38 PM, Michael Tokarev wrote: > 22.02.2021 13:58, John Paul Adrian Glaubitz wrote: >> Hi Laurent! >> >> On 2/22/21 11:50 AM, Laurent Vivier wrote: >>> Add --preserve-argv0 in qemu-binfmt-conf.sh to configure the preserve-argv0 >>> flag. >>> >>> This patch allows to use new flag in AT_FLAGS to detect if >>> preserve-argv0 is configured for this interpreter: >>> argv[0] (the full pathname provided by binfmt-misc) is removed and >>> replaced by argv[1] (the original argv[0] provided by binfmt-misc when >>> 'P'/preserve-arg[0] is set) >> >> Would this patch finally fix the issue with the perl package in Debian? [1] > > It's been fixed a week or so ago. Doesn't the patch require a kernel fix which is only present in Linux 5.12? @Laurent: Could you help clarify the difference of both fixes? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] linux-user: manage binfmt-misc preserve-arg[0] flag
Hi Laurent! On 2/22/21 11:50 AM, Laurent Vivier wrote: > Add --preserve-argv0 in qemu-binfmt-conf.sh to configure the preserve-argv0 > flag. > > This patch allows to use new flag in AT_FLAGS to detect if > preserve-argv0 is configured for this interpreter: > argv[0] (the full pathname provided by binfmt-misc) is removed and > replaced by argv[1] (the original argv[0] provided by binfmt-misc when > 'P'/preserve-arg[0] is set) Would this patch finally fix the issue with the perl package in Debian? [1] Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974004 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[Bug 1796520] Re: autogen crashes on qemu-sh4-user after 61dedf2af7
** Changed in: qemu Status: Expired => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1796520 Title: autogen crashes on qemu-sh4-user after 61dedf2af7 Status in QEMU: Incomplete Bug description: Running "autogen --help" crashes on qemu-sh4-user with: (sid-sh4-sbuild)root@nofan:/# autogen --help Unhandled trap: 0x180 pc=0xf64dd2de sr=0x pr=0xf63b9c74 fpscr=0x0008 spc=0x ssr=0x gbr=0xf61102a8 vbr=0x sgr=0x dbr=0x delayed_pc=0xf64dd2a0 fpul=0x0003 r0=0xf6fc1320 r1=0x r2=0x5dc4 r3=0xf67bfb50 r4=0xf6fc1230 r5=0xf6fc141c r6=0x03ff r7=0x r8=0x0004 r9=0xf63e20bc r10=0xf6fc141c r11=0xf63e28f0 r12=0xf63e2258 r13=0xf63eae1c r14=0x0804 r15=0xf6fc1220 r16=0x r17=0x r18=0x r19=0x r20=0x r21=0x r22=0x r23=0x (sid-sh4-sbuild)root@nofan:/# Bi-secting found this commit to be the culprit: 61dedf2af79fb5866dc7a0f972093682f2185e17 is the first bad commit commit 61dedf2af79fb5866dc7a0f972093682f2185e17 Author: Richard Henderson Date: Tue Jul 18 10:02:50 2017 -1000 target/sh4: Add missing FPSCR.PR == 0 checks Both frchg and fschg require PR == 0, otherwise undefined_operation. Reviewed-by: Aurelien Jarno Signed-off-by: Richard Henderson Message-Id: <20170718200255.31647-26-...@twiddle.net> Signed-off-by: Aurelien Jarno :04 04 980d79b69ae712f23a1e4c56983e97a843153b4a 1024c109f506c7ad57367c63bc8bbbc8a7a36cd7 M target Reverting 61dedf2af79fb5866dc7a0f972093682f2185e17 fixes the problem for me. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1796520/+subscriptions
Re: [PATCH 1/8] build-system: clean up TCG/TCI configury
Hello! On 1/13/21 3:23 PM, Helge Deller wrote: >> This is what that TCG interpreter provides for. eg would anyone >> really want to emulate aarch64 guest when runing on a hppa host ? > > In debian many packages directly and indirectly depend on the qemu > source package, because it provides - beside the emulator - various > userspace tools which are necessary natively, like e.g. qemu-img. I agree, that this a problem and it would be great if QEMU could be fixed that it builds on all targets, not necessarily with all features available. Currently, it looks like this: > https://buildd.debian.org/status/package.php?p=qemu=sid Note: The build failure on sparc64 is a bug in the device-tree-compiler package which has not been fixed in Debian yet, see: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977031 > In the past building those tools failed on hppa because the configure script > detected that neither native TCG nor TCG interpreter support was possible. > As such the configuration aborted and no tools were built. > So, the change should still make it possible to enable building the userspace > tools. I agree. > On the other side, sometimes even a slow TCG-interpreter enabled qemu > for other arches can be useful. It's not about speed, but about the > *possibility* to emulate small pieces of different code, e.g. > cross-compilers, bios-tools and such. It's not used often, but it > can be handy. I also agree here. > That said, if it doesn't hurt I think we should not disable something > which can be useful (this applies to all architectures). True. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 1/8] build-system: clean up TCG/TCI configury
Hello! On 1/13/21 2:09 PM, Philippe Mathieu-Daudé wrote: >> ia64 is a dead host architecture and doesn't exist in any OS distro that >> we target anymore, so I don't think we need to consider it. >> >> Likewise parisc/hppa doesn't seem exist in Debian since Squeeze, so I >> think we can rule that out too. Both hppa and ia64 are maintained as unofficial ports in Debian: > https://cdimage.debian.org/cdimage/ports/snapshots/2021-01-03/ >> Only sh4 still seems to be supported in Debian. I expect the primary >> need there is for sh4 guest support rather than sh4 host support. Same applies to sh4: > https://cdimage.debian.org/cdimage/ports/debian-installer/2021-01-03/sh4/ Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Deprecation of the LM32 target
Hello! On 12/26/20 9:39 AM, Thomas Huth wrote: > the problem is not that the target CPU is old, but rather that according to > the (former?) maintainer, there are no users left: > > https://www.mail-archive.com/qemu-devel@nongnu.org/msg605024.html > > So it got marked as deprecated in this commit here: > > https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d84980051229fa43c96b3 > > Without maintainer and without users, there is no point in keeping this > target, is there? I'm not sure how you determine whether there are people using the code or not. There is no really user tracking in QEMU, is there? And the maintainer's claim that RISC-V takes over makes no sense either. The point of emulators is to be able to run old and existing software. If a target had only a justification to exist while it's commercially viable, you would have to remove 90% of the targets in QEMU. I mean, the whole point of an emulator is being able to run existing code on modern hardware, usually because the old hardware is no longer available. And as long as the target is functional, I don't see a point in taking away the functionality. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Deprecation of the LM32 target
Hello! I was just browsing through the QEMU Christmas Calendar [1] and noticed the announcement for the deprecation of the LM32 target. I'm not sure what the motivation of the deprecation is, but isn't one of the big selling points of QEMU to support deprecated targets? If QEMU eventually ends up supporting commercially available targets only and kicking out everything that is obsolete, I'm not sure what the point of QEMU would be in the first place as products like VMWare and VirtualBox already provide virtualization functionality. Please don't deprecate targets just because they're old. Thanks, Adrian > [1] https://www.qemu-advent-calendar.org/2020/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[Bug 1907427] Re: Build on sparc64 fails with "undefined reference to `fdt_check_full'"
The issue has been fixed in the device-tree-compiler package here: > https://git.kernel.org/pub/scm/utils/dtc/dtc.git/commit/?id=b28464a550c536296439b5785ed8852d1e15b35b I have filed a Debian bug report asking to backport the patch: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977031 Nevertheless, qemu should check for the presence of libfdt >= 1.5.1, so this is still a valid bug report. ** Bug watch added: Debian Bug tracker #977031 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977031 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1907427 Title: Build on sparc64 fails with "undefined reference to `fdt_check_full'" Status in QEMU: New Bug description: Trying to build QEMU on sparc64 fails with: [4648/8435] c++ -o qemu-system-ppc64 qemu-system-ppc64.p/softmmu_main.c.o libcommon.fa.p/ui_vnc-auth-sasl.c.o libcommon.fa.p/migration_colo-failover.c.o libcommon.fa.p/hw_input_vhost-user-input.c.o libcommon.fa.p/replay_replay-random.c.o libcommon.fa.p/hw_9pfs_codir.c.o libcommon.fa.p/hw_display_edid-region.c.o libcommon.fa.p/hw_net_vhost_net.c.o libcommon.fa.p/hw_isa_i82378.c.o libcommon.fa.p/backends_rng-egd.c.o libcommon.fa.p/hw_usb_core.c.o libcommon.fa.p/hw_pci-bridge_i82801b11.c.o libcommon.fa.p/net_tap.c.o libcommon.fa.p/hw_ipack_ipack.c.o libcommon.fa.p/hw_scsi_mptconfig.c.o libcommon.fa.p/hw_usb_libhw.c.o libcommon.fa.p/hw_display_sm501.c.o libcommon.fa.p/hw_net_rocker_rocker_world.c.o libcommon.fa.p/fsdev_qemu-fsdev.c.o libcommon.fa.p/backends_tpm_tpm_util.c.o libcommon.fa.p/net_tap-linux.c.o libcommon.fa.p/hw_net_rocker_rocker_fp.c.o libcommon.fa.p/hw_usb_dev-uas.c.o libcommon.fa.p/hw_net_fsl_etsec_miim.c.o libcommon.fa.p/net_queue.c.o libcommon.fa.p/hw_isa_isa-superio.c.o libcommon.fa.p/migration_global_state.c.o libcommon.fa.p/backends_rng-random.c.o libcommon.fa.p/hw_ipmi_ipmi_bmc_extern.c.o libcommon.fa.p/migration_postcopy-ram.c.o libcommon.fa.p/hw_scsi_megasas.c.o libcommon.fa.p/hw_acpi_acpi-stub.c.o libcommon.fa.p/hw_nvram_mac_nvram.c.o libcommon.fa.p/hw_net_pcnet-pci.c.o libcommon.fa.p/cpus-common.c.o libcommon.fa.p/hw_core_qdev-properties-system.c.o libcommon.fa.p/migration_colo.c.o libcommon.fa.p/ui_spice-module.c.o libcommon.fa.p/hw_usb_hcd-ehci-pci.c.o libcommon.fa.p/migration_exec.c.o libcommon.fa.p/hw_input_adb-kbd.c.o libcommon.fa.p/hw_timer_xilinx_timer.c.o libcommon.fa.p/hw_cpu_core.c.o libcommon.fa.p/chardev_msmouse.c.o libcommon.fa.p/migration_socket.c.o libcommon.fa.p/hw_9pfs_9p-synth.c.o libcommon.fa.p/backends_dbus-vmstate.c.o libcommon.fa.p/net_colo-compare.c.o libcommon.fa.p/hw_misc_macio_cuda.c.o libcommon.fa.p/hw_audio_intel-hda.c.o libcommon.fa.p/audio_audio_legacy.c.o (...) libio.fa libchardev.fa -Wl,--no-whole-archive -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -m64 -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,--as-needed -fstack-protector-strong libmigration.fa -Wl,--start-group libqemuutil.a contrib/libvhost-user/libvhost-user.a libqmp.fa libhwcore.fa libblockdev.fa libblock.fa libcrypto.fa libauthz.fa libqom.fa libio.fa libchardev.fa @block.syms @qemu.syms /usr/lib/gcc/sparc64-linux-gnu/10/../../../sparc64-linux-gnu/libfdt.so /usr/lib/sparc64-linux-gnu/libcapstone.so -lepoxy -lgbm /usr/lib/sparc64-linux-gnu/libpixman-1.so /usr/lib/sparc64-linux-gnu/libz.so /usr/lib/sparc64-linux-gnu/libslirp.so /usr/lib/sparc64-linux-gnu/libglib-2.0.so -lrdmacm -libverbs -libumad -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 /usr/lib/gcc/sparc64-linux-gnu/10/../../../sparc64-linux-gnu/libsasl2.so @block.syms -lusb-1.0 /lib/sparc64-linux-gnu/libudev.so /usr/lib/sparc64-linux-gnu/libpng16.so -lvdeplug /usr/lib/sparc64-linux-gnu/libjpeg.so -pthread -luring -lgnutls -lutil -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lm -Wl,--export-dynamic -lgmodule-2.0 -lglib-2.0 -laio -luring -lgnutls -lnettle -lstdc++ -Wl,--end-group /usr/bin/ld: libqemu-ppc64-softmmu.fa.p/hw_ppc_spapr_hcall.c.o: in function `h_update_dt': ./b/qemu/../../hw/ppc/spapr_hcall.c:1966: undefined reference to `fdt_check_full' collect2: error: ld returned 1 exit status Full build log available at: https://buildd.debian.org/status/fetch.php?pkg=qemu=sparc64=1%3A5.2%2Bdfsg-1=1607502300=0 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1907427/+subscriptions
[Bug 1907427] Re: Build on sparc64 fails with "undefined reference to `fdt_check_full'"
Indeed, libfdt has been failing to build from source on sparc64 since version 1.4.7 due to the testsuite crashing with unaligned access: > https://buildd.debian.org/status/fetch.php?pkg=device-tree- compiler=sparc64=1.6.0-1=1605385435=0 libfdt-dev probably contains some fancy pointer arithmetic resulting in unaligned access which is not allowed but not recognized by gcc. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1907427 Title: Build on sparc64 fails with "undefined reference to `fdt_check_full'" Status in QEMU: New Bug description: Trying to build QEMU on sparc64 fails with: [4648/8435] c++ -o qemu-system-ppc64 qemu-system-ppc64.p/softmmu_main.c.o libcommon.fa.p/ui_vnc-auth-sasl.c.o libcommon.fa.p/migration_colo-failover.c.o libcommon.fa.p/hw_input_vhost-user-input.c.o libcommon.fa.p/replay_replay-random.c.o libcommon.fa.p/hw_9pfs_codir.c.o libcommon.fa.p/hw_display_edid-region.c.o libcommon.fa.p/hw_net_vhost_net.c.o libcommon.fa.p/hw_isa_i82378.c.o libcommon.fa.p/backends_rng-egd.c.o libcommon.fa.p/hw_usb_core.c.o libcommon.fa.p/hw_pci-bridge_i82801b11.c.o libcommon.fa.p/net_tap.c.o libcommon.fa.p/hw_ipack_ipack.c.o libcommon.fa.p/hw_scsi_mptconfig.c.o libcommon.fa.p/hw_usb_libhw.c.o libcommon.fa.p/hw_display_sm501.c.o libcommon.fa.p/hw_net_rocker_rocker_world.c.o libcommon.fa.p/fsdev_qemu-fsdev.c.o libcommon.fa.p/backends_tpm_tpm_util.c.o libcommon.fa.p/net_tap-linux.c.o libcommon.fa.p/hw_net_rocker_rocker_fp.c.o libcommon.fa.p/hw_usb_dev-uas.c.o libcommon.fa.p/hw_net_fsl_etsec_miim.c.o libcommon.fa.p/net_queue.c.o libcommon.fa.p/hw_isa_isa-superio.c.o libcommon.fa.p/migration_global_state.c.o libcommon.fa.p/backends_rng-random.c.o libcommon.fa.p/hw_ipmi_ipmi_bmc_extern.c.o libcommon.fa.p/migration_postcopy-ram.c.o libcommon.fa.p/hw_scsi_megasas.c.o libcommon.fa.p/hw_acpi_acpi-stub.c.o libcommon.fa.p/hw_nvram_mac_nvram.c.o libcommon.fa.p/hw_net_pcnet-pci.c.o libcommon.fa.p/cpus-common.c.o libcommon.fa.p/hw_core_qdev-properties-system.c.o libcommon.fa.p/migration_colo.c.o libcommon.fa.p/ui_spice-module.c.o libcommon.fa.p/hw_usb_hcd-ehci-pci.c.o libcommon.fa.p/migration_exec.c.o libcommon.fa.p/hw_input_adb-kbd.c.o libcommon.fa.p/hw_timer_xilinx_timer.c.o libcommon.fa.p/hw_cpu_core.c.o libcommon.fa.p/chardev_msmouse.c.o libcommon.fa.p/migration_socket.c.o libcommon.fa.p/hw_9pfs_9p-synth.c.o libcommon.fa.p/backends_dbus-vmstate.c.o libcommon.fa.p/net_colo-compare.c.o libcommon.fa.p/hw_misc_macio_cuda.c.o libcommon.fa.p/hw_audio_intel-hda.c.o libcommon.fa.p/audio_audio_legacy.c.o (...) libio.fa libchardev.fa -Wl,--no-whole-archive -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -m64 -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,--as-needed -fstack-protector-strong libmigration.fa -Wl,--start-group libqemuutil.a contrib/libvhost-user/libvhost-user.a libqmp.fa libhwcore.fa libblockdev.fa libblock.fa libcrypto.fa libauthz.fa libqom.fa libio.fa libchardev.fa @block.syms @qemu.syms /usr/lib/gcc/sparc64-linux-gnu/10/../../../sparc64-linux-gnu/libfdt.so /usr/lib/sparc64-linux-gnu/libcapstone.so -lepoxy -lgbm /usr/lib/sparc64-linux-gnu/libpixman-1.so /usr/lib/sparc64-linux-gnu/libz.so /usr/lib/sparc64-linux-gnu/libslirp.so /usr/lib/sparc64-linux-gnu/libglib-2.0.so -lrdmacm -libverbs -libumad -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 /usr/lib/gcc/sparc64-linux-gnu/10/../../../sparc64-linux-gnu/libsasl2.so @block.syms -lusb-1.0 /lib/sparc64-linux-gnu/libudev.so /usr/lib/sparc64-linux-gnu/libpng16.so -lvdeplug /usr/lib/sparc64-linux-gnu/libjpeg.so -pthread -luring -lgnutls -lutil -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lm -Wl,--export-dynamic -lgmodule-2.0 -lglib-2.0 -laio -luring -lgnutls -lnettle -lstdc++ -Wl,--end-group /usr/bin/ld: libqemu-ppc64-softmmu.fa.p/hw_ppc_spapr_hcall.c.o: in function `h_update_dt': ./b/qemu/../../hw/ppc/spapr_hcall.c:1966: undefined reference to `fdt_check_full' collect2: error: ld returned 1 exit status Full build log available at: https://buildd.debian.org/status/fetch.php?pkg=qemu=sparc64=1%3A5.2%2Bdfsg-1=1607502300=0 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1907427/+subscriptions
[Bug 1907427] [NEW] Build on sparc64 fails with "undefined reference to `fdt_check_full'"
Public bug reported: Trying to build QEMU on sparc64 fails with: [4648/8435] c++ -o qemu-system-ppc64 qemu-system-ppc64.p/softmmu_main.c.o libcommon.fa.p/ui_vnc-auth-sasl.c.o libcommon.fa.p/migration_colo-failover.c.o libcommon.fa.p/hw_input_vhost-user-input.c.o libcommon.fa.p/replay_replay-random.c.o libcommon.fa.p/hw_9pfs_codir.c.o libcommon.fa.p/hw_display_edid-region.c.o libcommon.fa.p/hw_net_vhost_net.c.o libcommon.fa.p/hw_isa_i82378.c.o libcommon.fa.p/backends_rng-egd.c.o libcommon.fa.p/hw_usb_core.c.o libcommon.fa.p/hw_pci-bridge_i82801b11.c.o libcommon.fa.p/net_tap.c.o libcommon.fa.p/hw_ipack_ipack.c.o libcommon.fa.p/hw_scsi_mptconfig.c.o libcommon.fa.p/hw_usb_libhw.c.o libcommon.fa.p/hw_display_sm501.c.o libcommon.fa.p/hw_net_rocker_rocker_world.c.o libcommon.fa.p/fsdev_qemu-fsdev.c.o libcommon.fa.p/backends_tpm_tpm_util.c.o libcommon.fa.p/net_tap-linux.c.o libcommon.fa.p/hw_net_rocker_rocker_fp.c.o libcommon.fa.p/hw_usb_dev-uas.c.o libcommon.fa.p/hw_net_fsl_etsec_miim.c.o libcommon.fa.p/net_queue.c.o libcommon.fa.p/hw_isa_isa-superio.c.o libcommon.fa.p/migration_global_state.c.o libcommon.fa.p/backends_rng-random.c.o libcommon.fa.p/hw_ipmi_ipmi_bmc_extern.c.o libcommon.fa.p/migration_postcopy-ram.c.o libcommon.fa.p/hw_scsi_megasas.c.o libcommon.fa.p/hw_acpi_acpi-stub.c.o libcommon.fa.p/hw_nvram_mac_nvram.c.o libcommon.fa.p/hw_net_pcnet-pci.c.o libcommon.fa.p/cpus-common.c.o libcommon.fa.p/hw_core_qdev-properties-system.c.o libcommon.fa.p/migration_colo.c.o libcommon.fa.p/ui_spice-module.c.o libcommon.fa.p/hw_usb_hcd-ehci-pci.c.o libcommon.fa.p/migration_exec.c.o libcommon.fa.p/hw_input_adb-kbd.c.o libcommon.fa.p/hw_timer_xilinx_timer.c.o libcommon.fa.p/hw_cpu_core.c.o libcommon.fa.p/chardev_msmouse.c.o libcommon.fa.p/migration_socket.c.o libcommon.fa.p/hw_9pfs_9p-synth.c.o libcommon.fa.p/backends_dbus-vmstate.c.o libcommon.fa.p/net_colo-compare.c.o libcommon.fa.p/hw_misc_macio_cuda.c.o libcommon.fa.p/hw_audio_intel-hda.c.o libcommon.fa.p/audio_audio_legacy.c.o (...) libio.fa libchardev.fa -Wl,--no-whole-archive -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -m64 -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,--as-needed -fstack-protector-strong libmigration.fa -Wl,--start-group libqemuutil.a contrib/libvhost-user/libvhost-user.a libqmp.fa libhwcore.fa libblockdev.fa libblock.fa libcrypto.fa libauthz.fa libqom.fa libio.fa libchardev.fa @block.syms @qemu.syms /usr/lib/gcc/sparc64-linux-gnu/10/../../../sparc64-linux-gnu/libfdt.so /usr/lib/sparc64-linux-gnu/libcapstone.so -lepoxy -lgbm /usr/lib/sparc64-linux-gnu/libpixman-1.so /usr/lib/sparc64-linux-gnu/libz.so /usr/lib/sparc64-linux-gnu/libslirp.so /usr/lib/sparc64-linux-gnu/libglib-2.0.so -lrdmacm -libverbs -libumad -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 /usr/lib/gcc/sparc64-linux-gnu/10/../../../sparc64-linux-gnu/libsasl2.so @block.syms -lusb-1.0 /lib/sparc64-linux-gnu/libudev.so /usr/lib/sparc64-linux-gnu/libpng16.so -lvdeplug /usr/lib/sparc64-linux-gnu/libjpeg.so -pthread -luring -lgnutls -lutil -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lm -Wl,--export-dynamic -lgmodule-2.0 -lglib-2.0 -laio -luring -lgnutls -lnettle -lstdc++ -Wl,--end-group /usr/bin/ld: libqemu-ppc64-softmmu.fa.p/hw_ppc_spapr_hcall.c.o: in function `h_update_dt': ./b/qemu/../../hw/ppc/spapr_hcall.c:1966: undefined reference to `fdt_check_full' collect2: error: ld returned 1 exit status Full build log available at: https://buildd.debian.org/status/fetch.php?pkg=qemu=sparc64=1%3A5.2%2Bdfsg-1=1607502300=0 ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1907427 Title: Build on sparc64 fails with "undefined reference to `fdt_check_full'" Status in QEMU: New Bug description: Trying to build QEMU on sparc64 fails with: [4648/8435] c++ -o qemu-system-ppc64 qemu-system-ppc64.p/softmmu_main.c.o libcommon.fa.p/ui_vnc-auth-sasl.c.o libcommon.fa.p/migration_colo-failover.c.o libcommon.fa.p/hw_input_vhost-user-input.c.o libcommon.fa.p/replay_replay-random.c.o libcommon.fa.p/hw_9pfs_codir.c.o libcommon.fa.p/hw_display_edid-region.c.o libcommon.fa.p/hw_net_vhost_net.c.o libcommon.fa.p/hw_isa_i82378.c.o libcommon.fa.p/backends_rng-egd.c.o libcommon.fa.p/hw_usb_core.c.o libcommon.fa.p/hw_pci-bridge_i82801b11.c.o libcommon.fa.p/net_tap.c.o libcommon.fa.p/hw_ipack_ipack.c.o libcommon.fa.p/hw_scsi_mptconfig.c.o libcommon.fa.p/hw_usb_libhw.c.o libcommon.fa.p/hw_display_sm501.c.o libcommon.fa.p/hw_net_rocker_rocker_world.c.o libcommon.fa.p/fsdev_qemu-fsdev.c.o libcommon.fa.p/backends_tpm_tpm_util.c.o libcommon.fa.p/net_tap-linux.c.o libcommon.fa.p/hw_net_rocker_rocker_fp.c.o libcommon.fa.p/hw_usb_dev-uas.c.o
[Bug 1796520] Re: autogen crashes on qemu-sh4-user after 61dedf2af7
Bug is still pending on git master. Have not pinged the SuperH crew yet. Will try to do that tomorrow, I'll also ping glibc upstream. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1796520 Title: autogen crashes on qemu-sh4-user after 61dedf2af7 Status in QEMU: Incomplete Bug description: Running "autogen --help" crashes on qemu-sh4-user with: (sid-sh4-sbuild)root@nofan:/# autogen --help Unhandled trap: 0x180 pc=0xf64dd2de sr=0x pr=0xf63b9c74 fpscr=0x0008 spc=0x ssr=0x gbr=0xf61102a8 vbr=0x sgr=0x dbr=0x delayed_pc=0xf64dd2a0 fpul=0x0003 r0=0xf6fc1320 r1=0x r2=0x5dc4 r3=0xf67bfb50 r4=0xf6fc1230 r5=0xf6fc141c r6=0x03ff r7=0x r8=0x0004 r9=0xf63e20bc r10=0xf6fc141c r11=0xf63e28f0 r12=0xf63e2258 r13=0xf63eae1c r14=0x0804 r15=0xf6fc1220 r16=0x r17=0x r18=0x r19=0x r20=0x r21=0x r22=0x r23=0x (sid-sh4-sbuild)root@nofan:/# Bi-secting found this commit to be the culprit: 61dedf2af79fb5866dc7a0f972093682f2185e17 is the first bad commit commit 61dedf2af79fb5866dc7a0f972093682f2185e17 Author: Richard Henderson Date: Tue Jul 18 10:02:50 2017 -1000 target/sh4: Add missing FPSCR.PR == 0 checks Both frchg and fschg require PR == 0, otherwise undefined_operation. Reviewed-by: Aurelien Jarno Signed-off-by: Richard Henderson Message-Id: <20170718200255.31647-26-...@twiddle.net> Signed-off-by: Aurelien Jarno :04 04 980d79b69ae712f23a1e4c56983e97a843153b4a 1024c109f506c7ad57367c63bc8bbbc8a7a36cd7 M target Reverting 61dedf2af79fb5866dc7a0f972093682f2185e17 fixes the problem for me. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1796520/+subscriptions
[Bug 1815911] Re: aptitude crashes qemu-m68k with handle_cpu_signal received signal outside vCPU context
Just verified it with a very recently compiled version of QEMU from git
master and, indeed, the bug seems to be fixed as I can no longer
reproduce the crash. The command executes correctly.
I guess it's safe to mark this as fixed.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815911
Title:
aptitude crashes qemu-m68k with handle_cpu_signal received signal
outside vCPU context
Status in QEMU:
Incomplete
Bug description:
When building a package with sbuild on Debian, sbuild can use aptitude
to resolve dependencies.
Recently, some changes introduced to aptitude or related packages
cause qemu to crash:
(sid-m68k-sbuild)root@nofan:/# aptitude -y --without-recommends -o
Dpkg::Options::=--force-confold -o
Aptitude::CmdLine::Ignore-Trust-Violations=false -o
Aptitude::ProblemResolver::StepScore=100 -o
Aptitude::ProblemResolver::SolutionCost="safety, priority,
non-default-versions" -o Aptitude::ProblemResolver::Hints::KeepDummy="reject
sbuild-build-depends-core-dummy :UNINST" -o
Aptitude::ProblemResolver::Keep-All-Level=55000 -o
Aptitude::ProblemResolver::Remove-Essential-Level=maximum install vim
Warning: Invalid locale (please review locale settings, this might lead to
problems later):
locale::facet::_S_create_c_locale name not valid
The following NEW packages will be installed:
libgpm2{a} vim vim-common{a} vim-runtime{a} xxd{a}
0 packages upgraded, 5 newly installed, 0 to remove and 1 not upgraded.
Need to get 7225 kB/7260 kB of archives. After unpacking 33.5 MB will be used.
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6019d1bf
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x601b64ab
Segmentation fault
(sid-m68k-sbuild)root@nofan:/#
The crash does not reproduce on real hardware running Debian unstable.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1815911/+subscriptions
[Bug 917645] Re: [Feature request] ia64-softmmu wanted
Someone is working on it, see: https://github.com/XVilka/qemu-ia64 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/917645 Title: [Feature request] ia64-softmmu wanted Status in HelenOS branches: Confirmed Status in QEMU: New Bug description: Qemu is missing support for full system emulation of the Itanium architecture, which is one of the main non-x86 server architectures today (despite the alleged decline in popularity). It would be really nice if someone had interest in adding full ia64 support to Qemu. Many OS projects could then use Qemu as the universal machine emulator for development and testing. Note that there is an open source Ski simulator which can emulate an ia64 CPU, memory and a couple of Ski-specific devices, but the project seems inactive and the simulated machine is too simplified (no real devices, no real firmware). Moreover, it'd be better to have one tool such as Qemu for all architectures of interest rather than one per each architecture. To manage notifications about this bug go to: https://bugs.launchpad.net/helenos/+bug/917645/+subscriptions
Re: [PATCH] linux-user: Ensure mmap_min_addr is non-zero
Hi!
On 7/24/20 11:23 PM, Richard Henderson wrote:
> When the chroot does not have /proc mounted, we can read neither
> /proc/sys/vm/mmap_min_addr nor /proc/sys/maps.
>
> The enforcement of mmap_min_addr in the host kernel is done by
> the security module, and so does not apply to processes owned
> by root. Which leads pgd_find_hole_fallback to succeed in probing
> a reservation at address 0. Which confuses pgb_reserved_va to
> believe that guest_base has not actually been initialized.
>
> We don't actually want NULL addresses to become accessible, so
> make sure that mmap_min_addr is initialized with a non-zero value.
>
> Buglink: https://bugs.launchpad.net/qemu/+bug/1888728
> Reported-by: John Paul Adrian Glaubitz
> Signed-off-by: Richard Henderson
> ---
> linux-user/main.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/linux-user/main.c b/linux-user/main.c
> index 3597e99bb1..75c9785157 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -758,14 +758,26 @@ int main(int argc, char **argv, char **envp)
>
> if ((fp = fopen("/proc/sys/vm/mmap_min_addr", "r")) != NULL) {
> unsigned long tmp;
> -if (fscanf(fp, "%lu", ) == 1) {
> +if (fscanf(fp, "%lu", ) == 1 && tmp != 0) {
> mmap_min_addr = tmp;
> -qemu_log_mask(CPU_LOG_PAGE, "host mmap_min_addr=0x%lx\n",
> mmap_min_addr);
> +qemu_log_mask(CPU_LOG_PAGE, "host mmap_min_addr=0x%lx\n",
> + mmap_min_addr);
> }
> fclose(fp);
> }
> }
>
> +/*
> + * We prefer to not make NULL pointers accessible to QEMU.
> + * If we're in a chroot with no /proc, fall back to 1 page.
> + */
> +if (mmap_min_addr == 0) {
> +mmap_min_addr = qemu_host_page_size;
> +qemu_log_mask(CPU_LOG_PAGE,
> + "host mmap_min_addr=0x%lx (fallback)\n",
> + mmap_min_addr);
> +}
> +
> /*
> * Prepare copy of argv vector for target.
> */
>
This fixes the problem for me, therefore:
Tested-by: John Paul Adrian Glaubitz
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[Bug 1888728] Re: Bare chroot in linux-user fails with pgb_reserved_va: Assertion `guest_base != 0' failed.
Here you go: https://people.debian.org/~glaubitz/sid-m68k-sbuild.tgz Thanks for looking into it! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1888728 Title: Bare chroot in linux-user fails with pgb_reserved_va: Assertion `guest_base != 0' failed. Status in QEMU: New Bug description: Trying to run a bare chroot with no additional bind mounts fails on git master (8ffa52c20d5693d454f65f2024a1494edfea65d4) with: root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/ qemu-m68k-static: /root/qemu/linux-user/elfload.c:2315: pgb_reserved_va: Assertion `guest_base != 0' failed. Aborted root@nofan:~/qemu> The problem can be worked around by bind-mounting /proc from the host system into the target chroot: root@nofan:~/qemu> mount -o bind /proc/ /local_scratch/sid-m68k-sbuild/proc/ root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/ bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) (sid-m68k-sbuild)root@nofan:/# Host system is an up-to-date Debian unstable (2020-07-23). I have not been able to bisect the issue yet since there is another annoying linux-user bug (virtual memory exhaustion) that was somewhere introduced and fixed between v5.0.0 and HEAD and overshadows the original Assertion failure bug. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1888728/+subscriptions
[Bug 1888728] [NEW] Bare chroot in linux-user fails with pgb_reserved_va: Assertion `guest_base != 0' failed.
Public bug reported: Trying to run a bare chroot with no additional bind mounts fails on git master (8ffa52c20d5693d454f65f2024a1494edfea65d4) with: root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/ qemu-m68k-static: /root/qemu/linux-user/elfload.c:2315: pgb_reserved_va: Assertion `guest_base != 0' failed. Aborted root@nofan:~/qemu> The problem can be worked around by bind-mounting /proc from the host system into the target chroot: root@nofan:~/qemu> mount -o bind /proc/ /local_scratch/sid-m68k-sbuild/proc/ root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/ bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) (sid-m68k-sbuild)root@nofan:/# Host system is an up-to-date Debian unstable (2020-07-23). I have not been able to bisect the issue yet since there is another annoying linux-user bug (virtual memory exhaustion) that was somewhere introduced and fixed between v5.0.0 and HEAD and overshadows the original Assertion failure bug. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1888728 Title: Bare chroot in linux-user fails with pgb_reserved_va: Assertion `guest_base != 0' failed. Status in QEMU: New Bug description: Trying to run a bare chroot with no additional bind mounts fails on git master (8ffa52c20d5693d454f65f2024a1494edfea65d4) with: root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/ qemu-m68k-static: /root/qemu/linux-user/elfload.c:2315: pgb_reserved_va: Assertion `guest_base != 0' failed. Aborted root@nofan:~/qemu> The problem can be worked around by bind-mounting /proc from the host system into the target chroot: root@nofan:~/qemu> mount -o bind /proc/ /local_scratch/sid-m68k-sbuild/proc/ root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/ bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) (sid-m68k-sbuild)root@nofan:/# Host system is an up-to-date Debian unstable (2020-07-23). I have not been able to bisect the issue yet since there is another annoying linux-user bug (virtual memory exhaustion) that was somewhere introduced and fixed between v5.0.0 and HEAD and overshadows the original Assertion failure bug. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1888728/+subscriptions
Re: [PATCH] target/m68k: implement fmove.l #,FPCR
Hi Laurent! On 5/31/20 2:09 PM, Laurent Vivier wrote: > I guess you are using my q800-dev branch? That's what I initially did, then I pulled from upstream. > In this branch, there is an attempt to manage unnormalized numbers that > seems to trigger this lock up. > > You can either use master + this patch or update your q800-dev branch > from my repo. However, I then still copied the compiled binary from the qemu-m68k where I first tested the patch. Guess I should be more careful when using the bash history with absolute paths ;). So, I can confirm it works for me. Tested-by: John Paul Adrian Glaubitz Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] target/m68k: implement fmove.l #,FPCR
Hi Laurent! On 5/31/20 1:02 PM, Laurent Vivier wrote: > The immediate value mode was ignored and instruction execution > ends to an invalid access mode. > > This was found running 'R' that set FPSR to 0 at startup with > a 'fmove.l #0,FPSR' in qemu-system-m68k emulation and triggers a > kernel crash: > (...) > Reported-by: John Paul Adrian Glaubitz > Signed-off-by: Laurent Vivier > --- > target/m68k/translate.c | 14 ++ > 1 file changed, 14 insertions(+) Thanks for the fix. I applied the patch, but I'm getting a lock-up now as you previously reported in the other discussion on the Linux/m68k mailing list: root@pacman:~# R [ 68.42] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [R:650] [ 68.42] Modules linked in: sg evdev mac_hid ip_tables x_tables sha1_generic hmac ipv6 nf_defrag_ipv6 autofs4 ext4 crc16 mbcache jbd2 crc32c_generic sd_mod t10_pi crc_t10dif sr_mod cdrom crct10dif_generic crct10dif_common mac_esp macsonic esp_scsi [ 68.42] Format 00 Vector: 0064 PC: 0002df9c Status: 2008Not tainted [ 68.42] ORIG_D0: D0: A2: c02e239a A1: ffa1 [ 68.42] A0: 3c9adf29 D5: 000d D4: 8002ce30 [ 68.42] D3: 8002b418 D2: 8002b4b4 D1: Is this related or a different bug? I have not seen these lockups on real hardware. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Build for qemu-sh4 broken since 2445971604c
On 2/15/20 2:53 PM, Philippe Mathieu-Daudé wrote: > On 2/15/20 11:53 AM, John Paul Adrian Glaubitz wrote: >> Hi! >> >> Currently trying to build qemu-sh4 in static configuration fails with: >> >> make[1]: Entering directory '/root/qemu/slirp' >> make[1]: Nothing to be done for 'all'. >> make[1]: Leaving directory '/root/qemu/slirp' >> CC sh4-linux-user/tcg/tcg-op-gvec.o >> /root/qemu/tcg/tcg-op-gvec.c:298:25: error: unknown type name >> ‘gen_helper_gvec_5_ptr’; did you mean ‘gen_helper_gvec_4_ptr’? >> 298 | gen_helper_gvec_5_ptr *fn) >> | ^ >> | gen_helper_gvec_4_ptr >> make[1]: *** [/root/qemu/rules.mak:69: tcg/tcg-op-gvec.o] Error 1 >> make: *** [Makefile:497: sh4-linux-user/all] Error 2 > > I believe your build directory is out of date and might have dangling old > files. Yes, this seems to have been the problem, thanks. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Build for qemu-sh4 broken since 2445971604c
Hi! Currently trying to build qemu-sh4 in static configuration fails with: make[1]: Entering directory '/root/qemu/slirp' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/root/qemu/slirp' CC sh4-linux-user/tcg/tcg-op-gvec.o /root/qemu/tcg/tcg-op-gvec.c:298:25: error: unknown type name ‘gen_helper_gvec_5_ptr’; did you mean ‘gen_helper_gvec_4_ptr’? 298 | gen_helper_gvec_5_ptr *fn) | ^ | gen_helper_gvec_4_ptr make[1]: *** [/root/qemu/rules.mak:69: tcg/tcg-op-gvec.o] Error 1 make: *** [Makefile:497: sh4-linux-user/all] Error 2 This seems to have been introduced with: commit 2445971604c1cfd3ec484457159f4ac300fb04d2 Author: Richard Henderson Date: Tue Feb 11 16:31:38 2020 -0800 tcg: Add tcg_gen_gvec_5_ptr Extend the vector generator infrastructure to handle 5 vector arguments. Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Alex Bennée Reviewed-by: Taylor Simpson Signed-off-by: Richard Henderson Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Booting Debian in qemu-system-alpha
On 1/27/20 8:47 AM, Philippe Mathieu-Daudé wrote: >> I'm considering setting up two qemu-based buildds for alpha in the cloud now. > > Nice! > > Looking at cloud provider default plans, and problems with buildd on other > archs > (mipsel in particular) I recommend you to use at least 2GB instead of 512MB. Sure. I have two free cloud VMs which I will use for the alpha buildds. We're already using qemu for builds in Debian. For m68k and sh4, we're using qemu-user which helped discovering a lot of bugs, especially with qemu-user. Currently, we can't use qemu-system on m68k and sh4 since the system memory is limited there to 1 GiB and 64 MiB, although the latter is a limitation by qemu as far as I know. For riscv64, most buildds in Debian and build workers in openSUSE are based on qemu-system as cheap riscv64 hardware is still very hard to come by. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Booting Debian in qemu-system-alpha
On 1/24/20 9:19 PM, Richard Henderson wrote: > Oh. Hah! I just tried again, cutting and pasting your command-line. You've > got unicode quotes, not ascii ' (\x27). That gets passed through to the > kernel > as-is and prevents console=ttyS0 from being parsed properly. Good catch. That helped. Thanks. I'm considering setting up two qemu-based buildds for alpha in the cloud now. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Booting Debian in qemu-system-alpha
Hi! Has anyone had any success recently booting Debian on qemu-system-alpha? I just built qemu-system using the alpha-softmmu target from git and tried to run Debian's Alpha port but the output hangs very early: root@nofan:/local_scratch/alpha-system> ./qemu-system-alpha -m 512 -nographic -drive file=disk.img,media=disk,format=raw,index=0 -L pc-bios/ -kernel vmlinux -append ‘console=ttyS0’ -initrd initrd.gz -net nic -net user -drive file=debian-10.0-alpha-NETINST-1.iso,if=ide,media=cdrom PCI: 00:00:0 class 0300 id 1013:00b8 PCI: region 0: 1000 PCI: region 1: 1200 PCI: 00:01:0 class 0200 id 8086:100e PCI: region 0: 1202 PCI: region 1: c000 PCI: 00:02:0 class 0101 id 1095:0646 PCI: region 0: c040 PCI: region 1: c048 PCI: region 3: c04c Debian ISO taken from [1]. Adrian > [1] > https://cdimage.debian.org/cdimage/ports/2019-01-25/debian-10.0-alpha-NETINST-1.iso -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Bug 1860553] Re: cmake crashes on qemu-alpha-user with Illegal Instruction
On 1/24/20 5:39 AM, Richard Henderson wrote: > # chroot $root > ... > # qemu-alpha-static -D logfile -d in_asm ./Bootstrap.cmk/cmake .. Last one seems to be a halt instruction: IN: 0x0040007fd988: halt Illegal instruction Full log in [1]. > [1] https://people.debian.org/~glaubitz/logfile -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1860553 Title: cmake crashes on qemu-alpha-user with Illegal Instruction Status in QEMU: New Bug description: I tried building cmake on Debian unstable for Alpha today using qemu- user and the compiled cmake binary crashed with "Illegal Instruction": g++ -Wl,-z,relro -Wl,--as-needed -g -O2 -fdebug-prefix-map=/<>=. -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -I/<>/Build/Bootstrap.cmk -I/<>/Source -I/<>/Source/LexerParser -I/<>/Utilities cmAddCustomCommandCommand.o cmAddCustomTargetCommand.o cmAddDefinitionsCommand.o cmAddDependenciesCommand.o cmAddExecutableCommand.o cmAddLibraryCommand.o cmAddSubDirectoryCommand.o cmAddTestCommand.o cmArgumentParser.o cmBreakCommand.o cmBuildCommand.o cmCMakeMinimumRequired.o cmCMakePolicyCommand.o cmCPackPropertiesGenerator.o cmCacheManager.o cmCommand.o cmCommandArgumentParserHelper.o cmCommands.o cmCommonTargetGenerator.o cmComputeComponentGraph.o cmComputeLinkDepends.o cmComputeLinkInformation.o cmComputeTargetDepends.o cmConditionEvaluator.o cmConfigureFileCommand.o cmContinueCommand.o cmCoreTryCompile.o cmCreateTestSourceList.o cmCustomCommand.o cmCustomCommandGenerator.o cmDefinePropertyCommand.o cmDefinitions.o cmDepends.o cmDependsC.o cmDisallowedCommand.o cmDocumentationFormatter.o cmEnableLanguageCommand.o cmEnableTestingCommand.o cmExecProgramCommand.o cmExecuteProcessCommand.o cmExpandedCommandArgument.o cmExportBuildFileGenerator.o cmExportFileGenerator.o cmExportInstallFileGenerator.o cmExportSet.o cmExportSetMap.o cmExportTryCompileFileGenerator.o cmExprParserHelper.o cmExternalMakefileProjectGenerator.o cmFileCommand.o cmFileCopier.o cmFileInstaller.o cmFileTime.o cmFileTimeCache.o cmFileTimes.o cmFindBase.o cmFindCommon.o cmFindFileCommand.o cmFindLibraryCommand.o cmFindPackageCommand.o cmFindPathCommand.o cmFindProgramCommand.o cmForEachCommand.o cmFunctionCommand.o cmFSPermissions.o cmGeneratedFileStream.o cmGeneratorExpression.o cmGeneratorExpressionContext.o cmGeneratorExpressionDAGChecker.o cmGeneratorExpressionEvaluationFile.o cmGeneratorExpressionEvaluator.o cmGeneratorExpressionLexer.o cmGeneratorExpressionNode.o cmGeneratorExpressionParser.o cmGeneratorTarget.o cmGetCMakePropertyCommand.o cmGetDirectoryPropertyCommand.o cmGetFilenameComponentCommand.o cmGetPipes.o cmGetPropertyCommand.o cmGetSourceFilePropertyCommand.o cmGetTargetPropertyCommand.o cmGetTestPropertyCommand.o cmGlobalCommonGenerator.o cmGlobalGenerator.o cmGlobalUnixMakefileGenerator3.o cmGlobVerificationManager.o cmHexFileConverter.o cmIfCommand.o cmIncludeCommand.o cmIncludeGuardCommand.o cmIncludeDirectoryCommand.o cmIncludeRegularExpressionCommand.o cmInstallCommand.o cmInstallCommandArguments.o cmInstallDirectoryGenerator.o cmInstallExportGenerator.o cmInstallFilesCommand.o cmInstallFilesGenerator.o cmInstallGenerator.o cmInstallScriptGenerator.o cmInstallSubdirectoryGenerator.o cmInstallTargetGenerator.o cmInstallTargetsCommand.o cmInstalledFile.o cmLinkDirectoriesCommand.o cmLinkItem.o cmLinkLineComputer.o cmLinkLineDeviceComputer.o cmListCommand.o cmListFileCache.o cmLocalCommonGenerator.o cmLocalGenerator.o cmLocalUnixMakefileGenerator3.o cmMSVC60LinkLineComputer.o cmMacroCommand.o cmMakeDirectoryCommand.o cmMakefile.o cmMakefileExecutableTargetGenerator.o cmMakefileLibraryTargetGenerator.o cmMakefileTargetGenerator.o cmMakefileUtilityTargetGenerator.o cmMarkAsAdvancedCommand.o cmMathCommand.o cmMessageCommand.o cmMessenger.o cmNewLineStyle.o cmOSXBundleGenerator.o cmOptionCommand.o cmOrderDirectories.o cmOutputConverter.o cmParseArgumentsCommand.o cmPathLabel.o cmPolicies.o cmProcessOutput.o cmProjectCommand.o cmProperty.o cmPropertyDefinition.o cmPropertyDefinitionMap.o cmPropertyMap.o cmReturnCommand.o cmRulePlaceholderExpander.o cmScriptGenerator.o cmSearchPath.o cmSeparateArgumentsCommand.o cmSetCommand.o cmSetDirectoryPropertiesCommand.o cmSetPropertyCommand.o cmSetSourceFilesPropertiesCommand.o cmSetTargetPropertiesCommand.o cmSetTestsPropertiesCommand.o cmSiteNameCommand.o cmSourceFile.o cmSourceFileLocation.o cmState.o cmStateDirectory.o cmStateSnapshot.o cmStringReplaceHelper.o cmStringCommand.o cmSubdirCommand.o cmSystemToo
[Bug 1860553] Re: cmake crashes on qemu-alpha-user with Illegal Instruction
Can someone remind me how I can print the disassembly in this case? root@epyc:~> qemu-alpha-static -cpu help Available CPUs: ev4-alpha-cpu ev5-alpha-cpu ev56-alpha-cpu ev6-alpha-cpu ev67-alpha-cpu ev68-alpha-cpu pca56-alpha-cpu root@epyc:~> export QEMU_CPU=ev68-alpha-cpu root@epyc:~> chroot /local_scratch/sid-alpha-sbuild/ bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) (sid-alpha-sbuild)root@epyc:/# cd /build/cmake-L20LIu/cmake-3.15.4/Build (sid-alpha-sbuild)root@epyc:/build/cmake-L20LIu/cmake-3.15.4/Build# ./Bootstrap.cmk/cmake .. Illegal instruction (sid-alpha-sbuild)root@epyc:/build/cmake-L20LIu/cmake-3.15.4/Build# I checked all documentation but qemu-monitor - which supports disassembly - seems to be available for qemu-system only. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1860553 Title: cmake crashes on qemu-alpha-user with Illegal Instruction Status in QEMU: New Bug description: I tried building cmake on Debian unstable for Alpha today using qemu- user and the compiled cmake binary crashed with "Illegal Instruction": g++ -Wl,-z,relro -Wl,--as-needed -g -O2 -fdebug-prefix-map=/<>=. -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -I/<>/Build/Bootstrap.cmk -I/<>/Source -I/<>/Source/LexerParser -I/<>/Utilities cmAddCustomCommandCommand.o cmAddCustomTargetCommand.o cmAddDefinitionsCommand.o cmAddDependenciesCommand.o cmAddExecutableCommand.o cmAddLibraryCommand.o cmAddSubDirectoryCommand.o cmAddTestCommand.o cmArgumentParser.o cmBreakCommand.o cmBuildCommand.o cmCMakeMinimumRequired.o cmCMakePolicyCommand.o cmCPackPropertiesGenerator.o cmCacheManager.o cmCommand.o cmCommandArgumentParserHelper.o cmCommands.o cmCommonTargetGenerator.o cmComputeComponentGraph.o cmComputeLinkDepends.o cmComputeLinkInformation.o cmComputeTargetDepends.o cmConditionEvaluator.o cmConfigureFileCommand.o cmContinueCommand.o cmCoreTryCompile.o cmCreateTestSourceList.o cmCustomCommand.o cmCustomCommandGenerator.o cmDefinePropertyCommand.o cmDefinitions.o cmDepends.o cmDependsC.o cmDisallowedCommand.o cmDocumentationFormatter.o cmEnableLanguageCommand.o cmEnableTestingCommand.o cmExecProgramCommand.o cmExecuteProcessCommand.o cmExpandedCommandArgument.o cmExportBuildFileGenerator.o cmExportFileGenerator.o cmExportInstallFileGenerator.o cmExportSet.o cmExportSetMap.o cmExportTryCompileFileGenerator.o cmExprParserHelper.o cmExternalMakefileProjectGenerator.o cmFileCommand.o cmFileCopier.o cmFileInstaller.o cmFileTime.o cmFileTimeCache.o cmFileTimes.o cmFindBase.o cmFindCommon.o cmFindFileCommand.o cmFindLibraryCommand.o cmFindPackageCommand.o cmFindPathCommand.o cmFindProgramCommand.o cmForEachCommand.o cmFunctionCommand.o cmFSPermissions.o cmGeneratedFileStream.o cmGeneratorExpression.o cmGeneratorExpressionContext.o cmGeneratorExpressionDAGChecker.o cmGeneratorExpressionEvaluationFile.o cmGeneratorExpressionEvaluator.o cmGeneratorExpressionLexer.o cmGeneratorExpressionNode.o cmGeneratorExpressionParser.o cmGeneratorTarget.o cmGetCMakePropertyCommand.o cmGetDirectoryPropertyCommand.o cmGetFilenameComponentCommand.o cmGetPipes.o cmGetPropertyCommand.o cmGetSourceFilePropertyCommand.o cmGetTargetPropertyCommand.o cmGetTestPropertyCommand.o cmGlobalCommonGenerator.o cmGlobalGenerator.o cmGlobalUnixMakefileGenerator3.o cmGlobVerificationManager.o cmHexFileConverter.o cmIfCommand.o cmIncludeCommand.o cmIncludeGuardCommand.o cmIncludeDirectoryCommand.o cmIncludeRegularExpressionCommand.o cmInstallCommand.o cmInstallCommandArguments.o cmInstallDirectoryGenerator.o cmInstallExportGenerator.o cmInstallFilesCommand.o cmInstallFilesGenerator.o cmInstallGenerator.o cmInstallScriptGenerator.o cmInstallSubdirectoryGenerator.o cmInstallTargetGenerator.o cmInstallTargetsCommand.o cmInstalledFile.o cmLinkDirectoriesCommand.o cmLinkItem.o cmLinkLineComputer.o cmLinkLineDeviceComputer.o cmListCommand.o cmListFileCache.o cmLocalCommonGenerator.o cmLocalGenerator.o cmLocalUnixMakefileGenerator3.o cmMSVC60LinkLineComputer.o cmMacroCommand.o cmMakeDirectoryCommand.o cmMakefile.o cmMakefileExecutableTargetGenerator.o cmMakefileLibraryTargetGenerator.o cmMakefileTargetGenerator.o cmMakefileUtilityTargetGenerator.o cmMarkAsAdvancedCommand.o cmMathCommand.o cmMessageCommand.o cmMessenger.o cmNewLineStyle.o cmOSXBundleGenerator.o cmOptionCommand.o cmOrderDirectories.o cmOutputConverter.o cmParseArgumentsCommand.o cmPathLabel.o cmPolicies.o cmProcessOutput.o cmProjectCommand.o cmProperty.o cmPropertyDefinition.o cmPropertyDefinitionMap.o cmPropertyMap.o cmReturnCommand.o cmRulePlaceholderExpander.o cmScriptGenerator.o cmSearchPath.o cmSeparateArgumentsCommand.o cmSetCommand.o cmSetDirectoryPropertiesCommand.o cmSetPropertyCommand.o cmSetSourceFilesPropertiesCommand.o cmSetTargetPropertiesCommand.o
[Bug 1860553] [NEW] cmake crashes on qemu-alpha-user with Illegal Instruction
Public bug reported: I tried building cmake on Debian unstable for Alpha today using qemu- user and the compiled cmake binary crashed with "Illegal Instruction": g++ -Wl,-z,relro -Wl,--as-needed -g -O2 -fdebug-prefix-map=/<>=. -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -I/<>/Build/Bootstrap.cmk -I/<>/Source -I/<>/Source/LexerParser -I/<>/Utilities cmAddCustomCommandCommand.o cmAddCustomTargetCommand.o cmAddDefinitionsCommand.o cmAddDependenciesCommand.o cmAddExecutableCommand.o cmAddLibraryCommand.o cmAddSubDirectoryCommand.o cmAddTestCommand.o cmArgumentParser.o cmBreakCommand.o cmBuildCommand.o cmCMakeMinimumRequired.o cmCMakePolicyCommand.o cmCPackPropertiesGenerator.o cmCacheManager.o cmCommand.o cmCommandArgumentParserHelper.o cmCommands.o cmCommonTargetGenerator.o cmComputeComponentGraph.o cmComputeLinkDepends.o cmComputeLinkInformation.o cmComputeTargetDepends.o cmConditionEvaluator.o cmConfigureFileCommand.o cmContinueCommand.o cmCoreTryCompile.o cmCreateTestSourceList.o cmCustomCommand.o cmCustomCommandGenerator.o cmDefinePropertyCommand.o cmDefinitions.o cmDepends.o cmDependsC.o cmDisallowedCommand.o cmDocumentationFormatter.o cmEnableLanguageCommand.o cmEnableTestingCommand.o cmExecProgramCommand.o cmExecuteProcessCommand.o cmExpandedCommandArgument.o cmExportBuildFileGenerator.o cmExportFileGenerator.o cmExportInstallFileGenerator.o cmExportSet.o cmExportSetMap.o cmExportTryCompileFileGenerator.o cmExprParserHelper.o cmExternalMakefileProjectGenerator.o cmFileCommand.o cmFileCopier.o cmFileInstaller.o cmFileTime.o cmFileTimeCache.o cmFileTimes.o cmFindBase.o cmFindCommon.o cmFindFileCommand.o cmFindLibraryCommand.o cmFindPackageCommand.o cmFindPathCommand.o cmFindProgramCommand.o cmForEachCommand.o cmFunctionCommand.o cmFSPermissions.o cmGeneratedFileStream.o cmGeneratorExpression.o cmGeneratorExpressionContext.o cmGeneratorExpressionDAGChecker.o cmGeneratorExpressionEvaluationFile.o cmGeneratorExpressionEvaluator.o cmGeneratorExpressionLexer.o cmGeneratorExpressionNode.o cmGeneratorExpressionParser.o cmGeneratorTarget.o cmGetCMakePropertyCommand.o cmGetDirectoryPropertyCommand.o cmGetFilenameComponentCommand.o cmGetPipes.o cmGetPropertyCommand.o cmGetSourceFilePropertyCommand.o cmGetTargetPropertyCommand.o cmGetTestPropertyCommand.o cmGlobalCommonGenerator.o cmGlobalGenerator.o cmGlobalUnixMakefileGenerator3.o cmGlobVerificationManager.o cmHexFileConverter.o cmIfCommand.o cmIncludeCommand.o cmIncludeGuardCommand.o cmIncludeDirectoryCommand.o cmIncludeRegularExpressionCommand.o cmInstallCommand.o cmInstallCommandArguments.o cmInstallDirectoryGenerator.o cmInstallExportGenerator.o cmInstallFilesCommand.o cmInstallFilesGenerator.o cmInstallGenerator.o cmInstallScriptGenerator.o cmInstallSubdirectoryGenerator.o cmInstallTargetGenerator.o cmInstallTargetsCommand.o cmInstalledFile.o cmLinkDirectoriesCommand.o cmLinkItem.o cmLinkLineComputer.o cmLinkLineDeviceComputer.o cmListCommand.o cmListFileCache.o cmLocalCommonGenerator.o cmLocalGenerator.o cmLocalUnixMakefileGenerator3.o cmMSVC60LinkLineComputer.o cmMacroCommand.o cmMakeDirectoryCommand.o cmMakefile.o cmMakefileExecutableTargetGenerator.o cmMakefileLibraryTargetGenerator.o cmMakefileTargetGenerator.o cmMakefileUtilityTargetGenerator.o cmMarkAsAdvancedCommand.o cmMathCommand.o cmMessageCommand.o cmMessenger.o cmNewLineStyle.o cmOSXBundleGenerator.o cmOptionCommand.o cmOrderDirectories.o cmOutputConverter.o cmParseArgumentsCommand.o cmPathLabel.o cmPolicies.o cmProcessOutput.o cmProjectCommand.o cmProperty.o cmPropertyDefinition.o cmPropertyDefinitionMap.o cmPropertyMap.o cmReturnCommand.o cmRulePlaceholderExpander.o cmScriptGenerator.o cmSearchPath.o cmSeparateArgumentsCommand.o cmSetCommand.o cmSetDirectoryPropertiesCommand.o cmSetPropertyCommand.o cmSetSourceFilesPropertiesCommand.o cmSetTargetPropertiesCommand.o cmSetTestsPropertiesCommand.o cmSiteNameCommand.o cmSourceFile.o cmSourceFileLocation.o cmState.o cmStateDirectory.o cmStateSnapshot.o cmStringReplaceHelper.o cmStringCommand.o cmSubdirCommand.o cmSystemTools.o cmTarget.o cmTargetCompileDefinitionsCommand.o cmTargetCompileFeaturesCommand.o cmTargetCompileOptionsCommand.o cmTargetIncludeDirectoriesCommand.o cmTargetLinkLibrariesCommand.o cmTargetPropCommandBase.o cmTargetPropertyComputer.o cmTargetSourcesCommand.o cmTest.o cmTestGenerator.o cmTimestamp.o cmTryCompileCommand.o cmTryRunCommand.o cmUnexpectedCommand.o cmUnsetCommand.o cmUVHandlePtr.o cmUVProcessChain.o cmVersion.o cmWhileCommand.o cmWorkingDirectory.o cmake.o cmakemain.o cmcmd.o cm_string_view.o cmCommandArgumentLexer.o cmCommandArgumentParser.o cmExprLexer.o cmExprParser.o cmListFileLexer.o Directory.o EncodingCXX.o FStream.o Glob.o RegularExpression.o SystemTools.o EncodingC.o ProcessUNIX.o String.o System.o Terminal.o uv-src-strscpy.c.o uv-src-timer.c.o uv-src-uv-common.c.o uv-src-unix-cmake-bootstrap.c.o
[Qemu-devel] [Bug 1796520] Re: autogen crashes on qemu-sh4-user after 61dedf2af7
We can ask both glibc upstream and some SuperH experts. I'll ask. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1796520 Title: autogen crashes on qemu-sh4-user after 61dedf2af7 Status in QEMU: Confirmed Bug description: Running "autogen --help" crashes on qemu-sh4-user with: (sid-sh4-sbuild)root@nofan:/# autogen --help Unhandled trap: 0x180 pc=0xf64dd2de sr=0x pr=0xf63b9c74 fpscr=0x0008 spc=0x ssr=0x gbr=0xf61102a8 vbr=0x sgr=0x dbr=0x delayed_pc=0xf64dd2a0 fpul=0x0003 r0=0xf6fc1320 r1=0x r2=0x5dc4 r3=0xf67bfb50 r4=0xf6fc1230 r5=0xf6fc141c r6=0x03ff r7=0x r8=0x0004 r9=0xf63e20bc r10=0xf6fc141c r11=0xf63e28f0 r12=0xf63e2258 r13=0xf63eae1c r14=0x0804 r15=0xf6fc1220 r16=0x r17=0x r18=0x r19=0x r20=0x r21=0x r22=0x r23=0x (sid-sh4-sbuild)root@nofan:/# Bi-secting found this commit to be the culprit: 61dedf2af79fb5866dc7a0f972093682f2185e17 is the first bad commit commit 61dedf2af79fb5866dc7a0f972093682f2185e17 Author: Richard Henderson Date: Tue Jul 18 10:02:50 2017 -1000 target/sh4: Add missing FPSCR.PR == 0 checks Both frchg and fschg require PR == 0, otherwise undefined_operation. Reviewed-by: Aurelien Jarno Signed-off-by: Richard Henderson Message-Id: <20170718200255.31647-26-...@twiddle.net> Signed-off-by: Aurelien Jarno :04 04 980d79b69ae712f23a1e4c56983e97a843153b4a 1024c109f506c7ad57367c63bc8bbbc8a7a36cd7 M target Reverting 61dedf2af79fb5866dc7a0f972093682f2185e17 fixes the problem for me. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1796520/+subscriptions
[Qemu-devel] [Bug 1839325] Re: Go programs crash on qemu-sh4 due to issues with atomics
Thanks. I will report this to Go/gcc upstream.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1839325
Title:
Go programs crash on qemu-sh4 due to issues with atomics
Status in QEMU:
New
Bug description:
After #1738545 [1] was fixed, Go applications work fine on qemu-arm
but still crash on qemu-sh4. From the backtrace, it looks like an
issue with the atomics in qemu-sh4:
(sid-sh4-sbuild)root@epyc:/# cat hello.go
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
(sid-sh4-sbuild)root@epyc:/# gccgo-9 hello.go -o hello
(sid-sh4-sbuild)root@epyc:/# ./hello
panic: (runtime runtime.errorString) (0x7f74527c,0x80a038)
fatal error: panic on system stack
panic: (runtime runtime.errorString) (0x7f74527c,0x80a038)
fatal error: panic on system stack
runtime stack:
runtime..z2finternal..z2fatomic.Load64
../../../src/libgo/go/runtime/internal/atomic/atomic.c:37
runtime_mstart
../../../src/libgo/runtime/proc.c:596
goroutine 1 [running]:
goroutine running on other thread; stack unavailable
runtime stack:
runtime..z2finternal..z2fatomic.Load64
../../../src/libgo/go/runtime/internal/atomic/atomic.c:37
runtime_mstart
../../../src/libgo/runtime/proc.c:596
(sid-sh4-sbuild)root@epyc:/#
The same sample Go program runs fine on my SH7785LCR SH4 evaluation
board:
root@tirpitz:~> uname -a
Linux tirpitz 3.16.7-ckt7 #8 PREEMPT Fri Oct 21 18:47:41 CEST 2016 sh4a
GNU/Linux
root@tirpitz:~> cat hello.go
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
root@tirpitz:~> gccgo-9 hello.go -o hello
root@tirpitz:~> ./hello
hello world
root@tirpitz:~>
Please note: In order to be able to reproduce this, one also needs to
revert commit 61dedf2af7 [2], otherwise the Go application crashes
differently:
(sid-sh4-sbuild)root@epyc:/# ./hello
Unhandled trap: 0x180
pc=0x7e5f7f9e sr=0x pr=0x7ee3d582 fpscr=0x00080004
spc=0x ssr=0x gbr=0x7e590480 vbr=0x
sgr=0x dbr=0x delayed_pc=0x7e5f7f60 fpul=0x00034f3b
r0=0x008007d4 r1=0x r2=0xfffe0b2a r3=0x0002
r4=0x008006e4 r5=0x00872000 r6=0x0020 r7=0x
r8=0x7f7bca7c r9=0x7fffebd4 r10=0x00800480 r11=0x7f7bc0f0
r12=0x7f7a3fa4 r13=0x008004c0 r14=0x7f7b2238 r15=0x7fffebd0
r16=0x r17=0x r18=0x r19=0x
r20=0x r21=0x r22=0x r23=0x
(sid-sh4-sbuild)root@epyc:/#
> [1] https://bugs.launchpad.net/bugs/1738545
> [2] https://bugs.launchpad.net/bugs/1796520
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1839325/+subscriptions
[Qemu-devel] [Bug 1796520] Re: autogen crashes on qemu-sh4-user after 61dedf2af7
I can provide access to a machine connected to the internet so you can test it yourself. I'll send you an email. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1796520 Title: autogen crashes on qemu-sh4-user after 61dedf2af7 Status in QEMU: Confirmed Bug description: Running "autogen --help" crashes on qemu-sh4-user with: (sid-sh4-sbuild)root@nofan:/# autogen --help Unhandled trap: 0x180 pc=0xf64dd2de sr=0x pr=0xf63b9c74 fpscr=0x0008 spc=0x ssr=0x gbr=0xf61102a8 vbr=0x sgr=0x dbr=0x delayed_pc=0xf64dd2a0 fpul=0x0003 r0=0xf6fc1320 r1=0x r2=0x5dc4 r3=0xf67bfb50 r4=0xf6fc1230 r5=0xf6fc141c r6=0x03ff r7=0x r8=0x0004 r9=0xf63e20bc r10=0xf6fc141c r11=0xf63e28f0 r12=0xf63e2258 r13=0xf63eae1c r14=0x0804 r15=0xf6fc1220 r16=0x r17=0x r18=0x r19=0x r20=0x r21=0x r22=0x r23=0x (sid-sh4-sbuild)root@nofan:/# Bi-secting found this commit to be the culprit: 61dedf2af79fb5866dc7a0f972093682f2185e17 is the first bad commit commit 61dedf2af79fb5866dc7a0f972093682f2185e17 Author: Richard Henderson Date: Tue Jul 18 10:02:50 2017 -1000 target/sh4: Add missing FPSCR.PR == 0 checks Both frchg and fschg require PR == 0, otherwise undefined_operation. Reviewed-by: Aurelien Jarno Signed-off-by: Richard Henderson Message-Id: <20170718200255.31647-26-...@twiddle.net> Signed-off-by: Aurelien Jarno :04 04 980d79b69ae712f23a1e4c56983e97a843153b4a 1024c109f506c7ad57367c63bc8bbbc8a7a36cd7 M target Reverting 61dedf2af79fb5866dc7a0f972093682f2185e17 fixes the problem for me. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1796520/+subscriptions
[Qemu-devel] [Bug 1839325] [NEW] Go programs crash on qemu-sh4 due to issues with atomics
Public bug reported:
After #1738545 [1] was fixed, Go applications work fine on qemu-arm but
still crash on qemu-sh4. From the backtrace, it looks like an issue with
the atomics in qemu-sh4:
(sid-sh4-sbuild)root@epyc:/# cat hello.go
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
(sid-sh4-sbuild)root@epyc:/# gccgo-9 hello.go -o hello
(sid-sh4-sbuild)root@epyc:/# ./hello
panic: (runtime runtime.errorString) (0x7f74527c,0x80a038)
fatal error: panic on system stack
panic: (runtime runtime.errorString) (0x7f74527c,0x80a038)
fatal error: panic on system stack
runtime stack:
runtime..z2finternal..z2fatomic.Load64
../../../src/libgo/go/runtime/internal/atomic/atomic.c:37
runtime_mstart
../../../src/libgo/runtime/proc.c:596
goroutine 1 [running]:
goroutine running on other thread; stack unavailable
runtime stack:
runtime..z2finternal..z2fatomic.Load64
../../../src/libgo/go/runtime/internal/atomic/atomic.c:37
runtime_mstart
../../../src/libgo/runtime/proc.c:596
(sid-sh4-sbuild)root@epyc:/#
The same sample Go program runs fine on my SH7785LCR SH4 evaluation
board:
root@tirpitz:~> uname -a
Linux tirpitz 3.16.7-ckt7 #8 PREEMPT Fri Oct 21 18:47:41 CEST 2016 sh4a
GNU/Linux
root@tirpitz:~> cat hello.go
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
root@tirpitz:~> gccgo-9 hello.go -o hello
root@tirpitz:~> ./hello
hello world
root@tirpitz:~>
Please note: In order to be able to reproduce this, one also needs to
revert commit 61dedf2af7 [2], otherwise the Go application crashes
differently:
(sid-sh4-sbuild)root@epyc:/# ./hello
Unhandled trap: 0x180
pc=0x7e5f7f9e sr=0x pr=0x7ee3d582 fpscr=0x00080004
spc=0x ssr=0x gbr=0x7e590480 vbr=0x
sgr=0x dbr=0x delayed_pc=0x7e5f7f60 fpul=0x00034f3b
r0=0x008007d4 r1=0x r2=0xfffe0b2a r3=0x0002
r4=0x008006e4 r5=0x00872000 r6=0x0020 r7=0x
r8=0x7f7bca7c r9=0x7fffebd4 r10=0x00800480 r11=0x7f7bc0f0
r12=0x7f7a3fa4 r13=0x008004c0 r14=0x7f7b2238 r15=0x7fffebd0
r16=0x r17=0x r18=0x r19=0x
r20=0x r21=0x r22=0x r23=0x
(sid-sh4-sbuild)root@epyc:/#
> [1] https://bugs.launchpad.net/bugs/1738545
> [2] https://bugs.launchpad.net/bugs/1796520
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1839325
Title:
Go programs crash on qemu-sh4 due to issues with atomics
Status in QEMU:
New
Bug description:
After #1738545 [1] was fixed, Go applications work fine on qemu-arm
but still crash on qemu-sh4. From the backtrace, it looks like an
issue with the atomics in qemu-sh4:
(sid-sh4-sbuild)root@epyc:/# cat hello.go
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
(sid-sh4-sbuild)root@epyc:/# gccgo-9 hello.go -o hello
(sid-sh4-sbuild)root@epyc:/# ./hello
panic: (runtime runtime.errorString) (0x7f74527c,0x80a038)
fatal error: panic on system stack
panic: (runtime runtime.errorString) (0x7f74527c,0x80a038)
fatal error: panic on system stack
runtime stack:
runtime..z2finternal..z2fatomic.Load64
../../../src/libgo/go/runtime/internal/atomic/atomic.c:37
runtime_mstart
../../../src/libgo/runtime/proc.c:596
goroutine 1 [running]:
goroutine running on other thread; stack unavailable
runtime stack:
runtime..z2finternal..z2fatomic.Load64
../../../src/libgo/go/runtime/internal/atomic/atomic.c:37
runtime_mstart
../../../src/libgo/runtime/proc.c:596
(sid-sh4-sbuild)root@epyc:/#
The same sample Go program runs fine on my SH7785LCR SH4 evaluation
board:
root@tirpitz:~> uname -a
Linux tirpitz 3.16.7-ckt7 #8 PREEMPT Fri Oct 21 18:47:41 CEST 2016 sh4a
GNU/Linux
root@tirpitz:~> cat hello.go
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
root@tirpitz:~> gccgo-9 hello.go -o hello
root@tirpitz:~> ./hello
hello world
root@tirpitz:~>
Please note: In order to be able to reproduce this, one also needs to
revert commit 61dedf2af7 [2], otherwise the Go application crashes
differently:
(sid-sh4-sbuild)root@epyc:/# ./hello
Unhandled trap: 0x180
pc=0x7e5f7f9e sr=0x pr=0x7ee3d582 fpscr=0x00080004
spc=0x ssr=0x gbr=0x7e590480 vbr=0x
sgr=0x dbr=0x delayed_pc=0x7e5f7f60 fpul=0x00034f3b
r0=0x008007d4 r1=0x r2=0xfffe0b2a r3=0x0002
r4=0x008006e4 r5=0x00872000 r6=0x0020 r7=0x
r8=0x7f7bca7c r9=0x7fffebd4 r10=0x00800480 r11=0x7f7bc0f0
r12=0x7f7a3fa4 r13=0x008004c0 r14=0x7f7b2238 r15=0x7fffebd0
r16=0x r17=0x r18=0x r19=0x
r20=0x r21=0x r22=0x
[Qemu-devel] [Bug 1738545] Re: Go binaries panic with "mmap errno 9" on qemu-user
I can confirm that the issue has been resolved on arm. Unfortunately, on
sh4, the Go binaries are still crashing, albeit differently now. I
verified that they work fine on real sh4 hardware.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1738545
Title:
Go binaries panic with "mmap errno 9" on qemu-user
Status in QEMU:
Fix Committed
Bug description:
Go binaries panic with "mmap errno 9" on qemu-user.
root@nofan:/# cat hello.go
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
root@nofan:/# gccgo-7 hello.go -o hello
root@nofan:/# ./hello
mmap errno 9
fatal error: mmap
runtime stack:
mmap errno 9
fatal error: mmap
panic during panic
runtime stack:
mmap errno 9
fatal error: mmap
stack trace unavailable
root@nofan:/#
Tested with qemu from git master with Debian unstable for armel.
Same binaries work fine on real hardware.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1738545/+subscriptions
[Qemu-devel] [Bug 1738545] Re: Go binaries panic with "mmap errno 9" on qemu-user
Oh, that's interesting. I will verify this and if it indeed works, I
will enable Go binaries for sh4 in Debian.
Thanks a lot for the update!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1738545
Title:
Go binaries panic with "mmap errno 9" on qemu-user
Status in QEMU:
Fix Committed
Bug description:
Go binaries panic with "mmap errno 9" on qemu-user.
root@nofan:/# cat hello.go
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
root@nofan:/# gccgo-7 hello.go -o hello
root@nofan:/# ./hello
mmap errno 9
fatal error: mmap
runtime stack:
mmap errno 9
fatal error: mmap
panic during panic
runtime stack:
mmap errno 9
fatal error: mmap
stack trace unavailable
root@nofan:/#
Tested with qemu from git master with Debian unstable for armel.
Same binaries work fine on real hardware.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1738545/+subscriptions
Re: [Qemu-devel] [PATCH 2/2] linux-user: manage binfmt-misc preserve-arg[0] flag
Hi! Sorry for the late reply! On 7/17/19 12:07 PM, Laurent Vivier wrote: > And I don't like to break existing things... > > What I can propose: > > 1- modify this patch to add a configure option: > >by default qemu will need the QEMU_ARGV0 but we will be able to > define at configure time it always runs with preserve-arg[0] flag > enabled (something like "--enable-preserve-arg0") > > [So debian will be able to provide qemu-user-static with this enabled by > default if you're not afraid to break debian users environment] This sounds like a reasonable approach for the time being, I agree with that. I could just pass that option to configure whenever I build new static qemu binaries for the buildds and I can drop your customized patch locally. > 2- try (again) to push in the kernel the binfmt_misc namespace that > allows to have per chroot basis binfmt configuration That would be cool, too. Has there been some discussion on this already? > 3- once 3 done, enable preserve-arg[0] by default You mean once "2 done"? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[Qemu-devel] [Bug 1836763] [NEW] Firebird crashes on qemu-m68k-user with pthread_mutex_init error
Public bug reported: Trying to use the Firebird database on qemu-m68k-user with a Debian chroot fails with the database crashing with "ConfigStorage: mutex pthread_mutex_init error, status = 95": (sid-m68k-sbuild)root@epyc:/# apt install firebird3.0-server Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: cpio libip4tc0 Use 'apt autoremove' to remove them. The following additional packages will be installed: firebird3.0-common firebird3.0-common-doc firebird3.0-server-core firebird3.0-utils libfbclient2 libib-util Suggested packages: firebird3.0-doc The following NEW packages will be installed: firebird3.0-common firebird3.0-common-doc firebird3.0-server firebird3.0-server-core firebird3.0-utils libfbclient2 libib-util 0 upgraded, 7 newly installed, 0 to remove and 4 not upgraded. Need to get 4,051 kB of archives. After this operation, 15.9 MB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-common-doc all 3.0.5.33100.ds4-3 [35.3 kB] Get:2 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-common all 3.0.5.33100.ds4-3 [14.5 kB] Get:3 http://ftp.ports.debian.org/debian-ports unstable/main m68k libfbclient2 m68k 3.0.5.33100.ds4-3 [496 kB] Get:4 http://ftp.ports.debian.org/debian-ports unstable/main m68k libib-util m68k 3.0.5.33100.ds4-3 [3,220 B] Get:5 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-server-core m68k 3.0.5.33100.ds4-3 [2,368 kB] Get:6 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-utils m68k 3.0.5.33100.ds4-3 [770 kB] Get:7 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-server m68k 3.0.5.33100.ds4-3 [365 kB] Fetched 4,051 kB in 2s (1,803 kB/s) debconf: delaying package configuration, since apt-utils is not installed E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device) Selecting previously unselected package firebird3.0-common-doc. (Reading database ... 33605 files and directories currently installed.) Preparing to unpack .../0-firebird3.0-common-doc_3.0.5.33100.ds4-3_all.deb ... Unpacking firebird3.0-common-doc (3.0.5.33100.ds4-3) ... Selecting previously unselected package firebird3.0-common. Preparing to unpack .../1-firebird3.0-common_3.0.5.33100.ds4-3_all.deb ... Unpacking firebird3.0-common (3.0.5.33100.ds4-3) ... Selecting previously unselected package libfbclient2:m68k. Preparing to unpack .../2-libfbclient2_3.0.5.33100.ds4-3_m68k.deb ... Unpacking libfbclient2:m68k (3.0.5.33100.ds4-3) ... Selecting previously unselected package libib-util:m68k. Preparing to unpack .../3-libib-util_3.0.5.33100.ds4-3_m68k.deb ... Unpacking libib-util:m68k (3.0.5.33100.ds4-3) ... Selecting previously unselected package firebird3.0-server-core:m68k. Preparing to unpack .../4-firebird3.0-server-core_3.0.5.33100.ds4-3_m68k.deb ... Unpacking firebird3.0-server-core:m68k (3.0.5.33100.ds4-3) ... Selecting previously unselected package firebird3.0-utils. Preparing to unpack .../5-firebird3.0-utils_3.0.5.33100.ds4-3_m68k.deb ... Unpacking firebird3.0-utils (3.0.5.33100.ds4-3) ... Selecting previously unselected package firebird3.0-server. Preparing to unpack .../6-firebird3.0-server_3.0.5.33100.ds4-3_m68k.deb ... Unpacking firebird3.0-server (3.0.5.33100.ds4-3) ... Setting up firebird3.0-common-doc (3.0.5.33100.ds4-3) ... Setting up firebird3.0-common (3.0.5.33100.ds4-3) ... Setting up libib-util:m68k (3.0.5.33100.ds4-3) ... Setting up libfbclient2:m68k (3.0.5.33100.ds4-3) ... Setting up firebird3.0-utils (3.0.5.33100.ds4-3) ... Setting up firebird3.0-server-core:m68k (3.0.5.33100.ds4-3) ... Setting up firebird3.0-server (3.0.5.33100.ds4-3) ... debconf: unable to initialize frontend: Dialog debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.) debconf: falling back to frontend: Readline Password for firebird 3.0 - Firebird has a special user named SYSDBA, which is the user that has access to all databases. SYSDBA can also create new databases and users. Because of this, it is necessary to secure SYSDBA with a password. The password is stored in /etc/firebird/3.0/SYSDBA.password (readable only by root). You may modify it there (don't forget to update the security database too, using the gsec utility), or you may use dpkg-reconfigure to update both. If you don't enter a password, a random one will be used (and stored in SYSDBA.password). Password for SYSDBA: adduser: Warning: The home directory `/var/lib/firebird' does not belong to the user you are currently creating. ConfigStorage: mutex pthread_mutex_init error, status = 95 qemu: uncaught target signal 6 (Aborted) - core dumped Aborted dpkg: error
Re: [Qemu-devel] [PATCH 2/2] linux-user: manage binfmt-misc preserve-arg[0] flag
Hi! > On Jul 14, 2019, at 3:40 PM, Laurent Vivier wrote: > > Add --preserve-arg0 in qemu-binfmt-conf.sh to configure the preserve-arg0 > flag. > > Now, if QEMU is started with -0 or QEMU_ARGV0 and an empty parameter > argv[0] (the full pathname provided by binfmt-misc) is removed and > replaced by argv[1] (the original argv[0] provided by binfmt-misc when > 'P'/preserve-arg[0] is set) > > For instance: > > $ sudo QEMU_ARGV0= chroot m68k-chroot sh -c 'echo $0' > sh > > without this patch: > > $ sudo chroot m68k-chroot sh -c 'echo $0' > /usr/bin/sh As a regular user of qemu-user (we’re using qemu-user to run Debian’s buildds for m68k and sh4), I would like to add that the idea of having to pass additional environment variables to make qemu behave as expected, i.e. as the real hardware, is sub-optimal. I would prefer that enabling the preserve flag with the qemu-binfmt.sh script would make qemu-user behave correctly. If I understand correctly, the current design with the environment variable was chosen because my preferred approach would break compatibility in certain cases. However, I think that correct emulation is more important than compatibility to an old broken behavior and I would therefore be in favor to make the correct behavior default. This will also be necessary when using qemu-user with Debian’s sbuild to “cross”-build packages with qemu-user. This particular bug was actually discovered while building Debian packages for m68k and sh4 using qemu-user. Thanks, Adrian PS: I have disabled receiving messages for this list, so please keep me CC’ed.
Re: [Qemu-devel] [Bug 1835839] Re: qemu-user: $0 incorrectly always reports absolute path
On 7/9/19 4:01 PM, Laurent Vivier wrote: > What is the content of: > > /etc/binfmt.d/qemu-m68k.conf > /proc/sys/fs/binfmt_misc/qemu-m68k root@nofan:~> cat /etc/binfmt.d/qemu-m68k.conf :qemu-m68k:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x04:\xff\xff\xff\xff\xff\xff\xfe\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-m68k-static:P root@nofan:~> cat /proc/sys/fs/binfmt_misc/qemu-m68k enabled interpreter /usr/bin/qemu-m68k-static flags: OCF offset 0 magic 7f454c46010201020004 mask ff00fffe root@nofan:~> > what is the result of "file sid-m68k-sbuild/usr/bin/qemu-m68k-static"? > > Bonus: if you don't want to copy qemu-m68k-static into the chroot, you > can use "--persistent" with qemu-binfmt-conf.sh. I'm doing that and I don't have a copy of qemu in the chroot. But I think I forgot to pass --persistent to the script while testing. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1835839 Title: qemu-user: $0 incorrectly always reports absolute path Status in QEMU: New Bug description: We just ran into an issue with the Perl package on Debian/m68k when being built with qemu-user [1]. The problem can be boiled down to qemu-user always reporting absolute paths for the shell variable $0 no matter on how the command was invoked. A simple reproducer is this: On normal system (no emulation): root@nofan:~> sh -c 'echo $0' sh root@nofan:~> On qemu-user: (sid-m68k-sbuild)root@nofan:/# sh -c 'echo $0' /bin/sh (sid-m68k-sbuild)root@nofan:/# > [1] https://lists.debian.org/debian-68k/2019/07/msg7.html To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1835839/+subscriptions
Re: [Qemu-devel] [Bug 1835839] Re: qemu-user: $0 incorrectly always reports absolute path
After building qemu-m68k, I did: root@nofan:~/qemu> scripts/qemu-binfmt-conf.sh --systemd m68k --qemu-path=/usr/bin --qemu-suffix=-static --preserve-arg0 yes --persistent yes Setting /usr/bin/qemu-m68k-static as binfmt interpreter for m68k for systemd-binfmt.service root@nofan:~/qemu> rm /usr/bin/qemu-m68k-static root@nofan:~/qemu> cp -av m68k-linux-user/qemu-m68k /usr/bin/qemu-m68k-static 'm68k-linux-user/qemu-m68k' -> '/usr/bin/qemu-m68k-static' root@nofan:~/qemu> systemctl restart binfmt-support.service root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/ (sid-m68k-sbuild)root@nofan:/# sh -c 'echo $0' /bin/sh (sid-m68k-sbuild)root@nofan:/# -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1835839 Title: qemu-user: $0 incorrectly always reports absolute path Status in QEMU: New Bug description: We just ran into an issue with the Perl package on Debian/m68k when being built with qemu-user [1]. The problem can be boiled down to qemu-user always reporting absolute paths for the shell variable $0 no matter on how the command was invoked. A simple reproducer is this: On normal system (no emulation): root@nofan:~> sh -c 'echo $0' sh root@nofan:~> On qemu-user: (sid-m68k-sbuild)root@nofan:/# sh -c 'echo $0' /bin/sh (sid-m68k-sbuild)root@nofan:/# > [1] https://lists.debian.org/debian-68k/2019/07/msg7.html To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1835839/+subscriptions
Re: [Qemu-devel] [Bug 1835839] Re: qemu-user: $0 incorrectly always reports absolute path
On 7/9/19 2:51 PM, Laurent Vivier wrote: > if you use systemctl, the parameter of "./scripts/qemu-binfmt-conf.sh" > must be "--systemd m68k" rather than "--debian". I tried that and I now get: root@nofan:/local_scratch/sid-m68k-sbuild> chroot . chroot: failed to run command ‘/bin/bash’: No such file or directory root@nofan:/local_scratch/sid-m68k-sbuild> >> But still don't get the correct path: >> >> (sid-m68k-sbuild)root@nofan:/# sh -c 'echo $0' >> /bin/sh >> (sid-m68k-sbuild)root@nofan:/# > > Well, I've tested that, and it should work... Oh, I'm not arguing that. I'm sure the error is on my side ;). I'm just trying to find out what I'm doing wrong. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1835839 Title: qemu-user: $0 incorrectly always reports absolute path Status in QEMU: New Bug description: We just ran into an issue with the Perl package on Debian/m68k when being built with qemu-user [1]. The problem can be boiled down to qemu-user always reporting absolute paths for the shell variable $0 no matter on how the command was invoked. A simple reproducer is this: On normal system (no emulation): root@nofan:~> sh -c 'echo $0' sh root@nofan:~> On qemu-user: (sid-m68k-sbuild)root@nofan:/# sh -c 'echo $0' /bin/sh (sid-m68k-sbuild)root@nofan:/# > [1] https://lists.debian.org/debian-68k/2019/07/msg7.html To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1835839/+subscriptions
Re: [Qemu-devel] [Bug 1835839] Re: qemu-user: $0 incorrectly always reports absolute path
On 7/9/19 1:54 PM, Laurent Vivier wrote: > ** Patch added: "Enable binfmt-misc preserve-arg[0] flag" > > https://bugs.launchpad.net/qemu/+bug/1835839/+attachment/5275869/+files/0001-linux-user-manage-binfmt-misc-preserve-arg-0-flags.patch Thanks! I just tried the patch and ran the setup script with: ./scripts/qemu-binfmt-conf.sh --debian --qemu-path=/usr/bin --qemu- suffix=-static --preserve-arg0 yes and: root@nofan:~/qemu> systemctl restart binfmt-support.service root@nofan:~/qemu> But still don't get the correct path: (sid-m68k-sbuild)root@nofan:/# sh -c 'echo $0' /bin/sh (sid-m68k-sbuild)root@nofan:/# Do I need to do anything else? -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1835839 Title: qemu-user: $0 incorrectly always reports absolute path Status in QEMU: New Bug description: We just ran into an issue with the Perl package on Debian/m68k when being built with qemu-user [1]. The problem can be boiled down to qemu-user always reporting absolute paths for the shell variable $0 no matter on how the command was invoked. A simple reproducer is this: On normal system (no emulation): root@nofan:~> sh -c 'echo $0' sh root@nofan:~> On qemu-user: (sid-m68k-sbuild)root@nofan:/# sh -c 'echo $0' /bin/sh (sid-m68k-sbuild)root@nofan:/# > [1] https://lists.debian.org/debian-68k/2019/07/msg7.html To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1835839/+subscriptions
[Qemu-devel] [Bug 1835839] [NEW] qemu-user: $0 incorrectly always reports absolute path
Public bug reported: We just ran into an issue with the Perl package on Debian/m68k when being built with qemu-user [1]. The problem can be boiled down to qemu-user always reporting absolute paths for the shell variable $0 no matter on how the command was invoked. A simple reproducer is this: On normal system (no emulation): root@nofan:~> sh -c 'echo $0' sh root@nofan:~> On qemu-user: (sid-m68k-sbuild)root@nofan:/# sh -c 'echo $0' /bin/sh (sid-m68k-sbuild)root@nofan:/# > [1] https://lists.debian.org/debian-68k/2019/07/msg7.html ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1835839 Title: qemu-user: $0 incorrectly always reports absolute path Status in QEMU: New Bug description: We just ran into an issue with the Perl package on Debian/m68k when being built with qemu-user [1]. The problem can be boiled down to qemu-user always reporting absolute paths for the shell variable $0 no matter on how the command was invoked. A simple reproducer is this: On normal system (no emulation): root@nofan:~> sh -c 'echo $0' sh root@nofan:~> On qemu-user: (sid-m68k-sbuild)root@nofan:/# sh -c 'echo $0' /bin/sh (sid-m68k-sbuild)root@nofan:/# > [1] https://lists.debian.org/debian-68k/2019/07/msg7.html To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1835839/+subscriptions
Re: [Qemu-devel] [Bug 1815911] Re: aptitude crashes qemu-m68k with handle_cpu_signal received signal outside vCPU context
On 2/15/19 1:47 PM, Laurent Vivier wrote:
> It seems it crashes during futex syscall:
>
> ...
> [pid 4] getpid()= 4
> [pid 4] tgkill(4, 24, SIGRT_1) = 0
> [pid24] <... futex resumed> ) = ? ERESTARTSYS (To be restarted if
> SA_RESTART is set)
> [pid24] --- SIGRT_1 {si_signo=SIGRT_1, si_code=SI_TKILL, si_pid=4,
> si_uid=0} ---
> [pid 4] futex(0x7f77abb4f610, FUTEX_WAIT_PRIVATE, 16777216, NULL
>
> [pid24] getpid()= 4
> [pid24] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x10}
> ---
> ...
The crash also reproduces with qemu-sh4, so it's not specific to m68k.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815911
Title:
aptitude crashes qemu-m68k with handle_cpu_signal received signal
outside vCPU context
Status in QEMU:
New
Bug description:
When building a package with sbuild on Debian, sbuild can use aptitude
to resolve dependencies.
Recently, some changes introduced to aptitude or related packages
cause qemu to crash:
(sid-m68k-sbuild)root@nofan:/# aptitude -y --without-recommends -o
Dpkg::Options::=--force-confold -o
Aptitude::CmdLine::Ignore-Trust-Violations=false -o
Aptitude::ProblemResolver::StepScore=100 -o
Aptitude::ProblemResolver::SolutionCost="safety, priority,
non-default-versions" -o Aptitude::ProblemResolver::Hints::KeepDummy="reject
sbuild-build-depends-core-dummy :UNINST" -o
Aptitude::ProblemResolver::Keep-All-Level=55000 -o
Aptitude::ProblemResolver::Remove-Essential-Level=maximum install vim
Warning: Invalid locale (please review locale settings, this might lead to
problems later):
locale::facet::_S_create_c_locale name not valid
The following NEW packages will be installed:
libgpm2{a} vim vim-common{a} vim-runtime{a} xxd{a}
0 packages upgraded, 5 newly installed, 0 to remove and 1 not upgraded.
Need to get 7225 kB/7260 kB of archives. After unpacking 33.5 MB will be used.
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6019d1bf
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x601b64ab
Segmentation fault
(sid-m68k-sbuild)root@nofan:/#
The crash does not reproduce on real hardware running Debian unstable.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1815911/+subscriptions
[Qemu-devel] [Bug 1815911] [NEW] aptitude crashes qemu-m68k with handle_cpu_signal received signal outside vCPU context
Public bug reported:
When building a package with sbuild on Debian, sbuild can use aptitude
to resolve dependencies.
Recently, some changes introduced to aptitude or related packages cause
qemu to crash:
(sid-m68k-sbuild)root@nofan:/# aptitude -y --without-recommends -o
Dpkg::Options::=--force-confold -o
Aptitude::CmdLine::Ignore-Trust-Violations=false -o
Aptitude::ProblemResolver::StepScore=100 -o
Aptitude::ProblemResolver::SolutionCost="safety, priority,
non-default-versions" -o Aptitude::ProblemResolver::Hints::KeepDummy="reject
sbuild-build-depends-core-dummy :UNINST" -o
Aptitude::ProblemResolver::Keep-All-Level=55000 -o
Aptitude::ProblemResolver::Remove-Essential-Level=maximum install vim
Warning: Invalid locale (please review locale settings, this might lead to
problems later):
locale::facet::_S_create_c_locale name not valid
The following NEW packages will be installed:
libgpm2{a} vim vim-common{a} vim-runtime{a} xxd{a}
0 packages upgraded, 5 newly installed, 0 to remove and 1 not upgraded.
Need to get 7225 kB/7260 kB of archives. After unpacking 33.5 MB will be used.
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6019d1bf
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x601b64ab
Segmentation fault
(sid-m68k-sbuild)root@nofan:/#
The crash does not reproduce on real hardware running Debian unstable.
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815911
Title:
aptitude crashes qemu-m68k with handle_cpu_signal received signal
outside vCPU context
Status in QEMU:
New
Bug description:
When building a package with sbuild on Debian, sbuild can use aptitude
to resolve dependencies.
Recently, some changes introduced to aptitude or related packages
cause qemu to crash:
(sid-m68k-sbuild)root@nofan:/# aptitude -y --without-recommends -o
Dpkg::Options::=--force-confold -o
Aptitude::CmdLine::Ignore-Trust-Violations=false -o
Aptitude::ProblemResolver::StepScore=100 -o
Aptitude::ProblemResolver::SolutionCost="safety, priority,
non-default-versions" -o Aptitude::ProblemResolver::Hints::KeepDummy="reject
sbuild-build-depends-core-dummy :UNINST" -o
Aptitude::ProblemResolver::Keep-All-Level=55000 -o
Aptitude::ProblemResolver::Remove-Essential-Level=maximum install vim
Warning: Invalid locale (please review locale settings, this might lead to
problems later):
locale::facet::_S_create_c_locale name not valid
The following NEW packages will be installed:
libgpm2{a} vim vim-common{a} vim-runtime{a} xxd{a}
0 packages upgraded, 5 newly installed, 0 to remove and 1 not upgraded.
Need to get 7225 kB/7260 kB of archives. After unpacking 33.5 MB will be used.
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6019d1bf
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x601b64ab
Segmentation fault
(sid-m68k-sbuild)root@nofan:/#
The crash does not reproduce on real hardware running Debian unstable.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1815911/+subscriptions
[Qemu-devel] [Bug 1737444] Re: gccgo setcontext conftest crashes qemu-sh4
This still reproduces on git master:
(sid-sh4-sbuild)root@nofan:/# gcc setcontext.c -o setcontext -lpthread
(sid-sh4-sbuild)root@nofan:/# ./setcontext
Unhandled trap: 0x180
pc=0x7f68e99e sr=0x pr=0x00400750 fpscr=0x0008
spc=0x ssr=0x gbr=0x7f7a2de8 vbr=0x
sgr=0x dbr=0x delayed_pc=0x7f68e960 fpul=0x
r0=0x00e11158 r1=0x r2=0x0001 r3=0x7590
r4=0x00e11068 r5=0x75c4 r6=0x75cc r7=0x
r8=0x004007f0 r9=0x r10=0x r11=0x
r12=0x7f79ec64 r13=0x r14=0x7538 r15=0x7538
r16=0x r17=0x r18=0x r19=0x
r20=0x r21=0x r22=0x r23=0x
(sid-sh4-sbuild)root@nofan:/#
And it is fixed by reverting 61dedf2af7
(sid-sh4-sbuild)root@nofan:/# ./setcontext
(sid-sh4-sbuild)root@nofan:/# echo $?
0
(sid-sh4-sbuild)root@nofan:/#
So it's presumably the same bug as
https://bugs.launchpad.net/qemu/+bug/1796520
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1737444
Title:
gccgo setcontext conftest crashes qemu-sh4
Status in QEMU:
New
Bug description:
While testing gccgo on sh4 to add SH platform definitions to libgo, I
discovered that the following conftest program which is part of the
libgo configure script crashes on qemu-sh4:
(sid-sh4-sbuild)root@z6:/# cat setcontext.c
#include
#include
#include
#include
__thread int tls;
static char stack[10 * 1024 * 1024];
static ucontext_t c;
/* Called via makecontext/setcontext. */
static void
cfn (void)
{
exit (tls);
}
/* Called via pthread_create. */
static void *
tfn (void *dummy)
{
/* The thread should still see this value after calling
setcontext. */
tls = 0;
setcontext ();
/* The call to setcontext should not return. */
abort ();
}
int
main ()
{
pthread_t tid;
/* The thread should not see this value. */
tls = 1;
if (getcontext () < 0)
abort ();
c.uc_stack.ss_sp = stack;
#ifdef MAKECONTEXT_STACK_TOP
c.uc_stack.ss_sp += sizeof stack;
#endif
c.uc_stack.ss_flags = 0;
c.uc_stack.ss_size = sizeof stack;
c.uc_link = NULL;
makecontext (, cfn, 0);
if (pthread_create (, NULL, tfn, NULL) != 0)
abort ();
if (pthread_join (tid, NULL) != 0)
abort ();
/* The thread should have called exit. */
abort ();
}
(sid-sh4-sbuild)root@z6:/# gcc -o setcontext -lpthread setcontext.c
(sid-sh4-sbuild)root@z6:/# ./setcontext
Unhandled trap: 0x180
pc=0x7f69235e sr=0x pr=0x00400710 fpscr=0x0008
spc=0x ssr=0x gbr=0x7f658478 vbr=0x
sgr=0x dbr=0x delayed_pc=0x7f692320 fpul=0x
r0=0x00e11158 r1=0x r2=0x0001 r3=0x72e0
r4=0x00e11068 r5=0x7314 r6=0x731c r7=0x
r8=0x004007b0 r9=0x r10=0x r11=0x
r12=0x7f79ac54 r13=0x r14=0x7288 r15=0x7288
r16=0x r17=0x r18=0x r19=0x
r20=0x r21=0x r22=0x r23=0x
(sid-sh4-sbuild)root@z6:/#
The same code works fine on my Renesas SH7785LCR evaluation board:
root@tirpitz:~> uname -a
Linux tirpitz 3.16.7-ckt7 #8 PREEMPT Fri Oct 21 18:47:41 CEST 2016 sh4a
GNU/Linux
root@tirpitz:~> gcc -o setcontext
[Qemu-devel] [Bug 1735384] Re: OpenJDK JVM segfaults on qemu-sh4 (regression)
This has been fixed now and Java works fine again on qemu-sh4 on git master: (sid-sh4-sbuild)root@nofan:/# java --version openjdk 10 2018-03-20 OpenJDK Runtime Environment (build 10+46-Debian-5) OpenJDK Zero VM (build 10+46-Debian-5, interpreted mode) (sid-sh4-sbuild)root@nofan:/# ** 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/1735384 Title: OpenJDK JVM segfaults on qemu-sh4 (regression) Status in QEMU: Fix Released Bug description: Some of the recent changes introduced a regression which makes the OpenJDK JVM crash on qemu-sh4: (sid-sh4-sbuild)root@nofan:/# java -version qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (sid-sh4-sbuild)root@nofan:/# An older version works fine: (sid-sh4-sbuild)root@nofan:/# java -version openjdk version "9.0.1" OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) (sid-sh4-sbuild)root@nofan:/# Haven't had time for bisecting this yet. Adrian To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1735384/+subscriptions
[Qemu-devel] [Bug 1796520] Re: autogen crashes on qemu-sh4-user after 61dedf2af7
This is still reproducible on git master: (sid-sh4-sbuild)root@nofan:/# autogen Unhandled trap: 0x180 pc=0x7f4da99e sr=0x pr=0x7f3bfc74 fpscr=0x0008 spc=0x ssr=0x gbr=0x7f114320 vbr=0x sgr=0x dbr=0x delayed_pc=0x7f4da960 fpul=0x0003 r0=0x7ffc130c r1=0x r2=0x5dc4 r3=0x7f7bfb54 r4=0x7ffc121c r5=0x7ffc1408 r6=0x03ff r7=0x r8=0x0004 r9=0x7f3e80bc r10=0x7ffc1408 r11=0x7f3e88f0 r12=0x7f3e8258 r13=0x7f3f0e1c r14=0x0804 r15=0x7ffc120c r16=0x r17=0x r18=0x r19=0x r20=0x r21=0x r22=0x r23=0x (sid-sh4-sbuild)root@nofan:/# Can we just revert 61dedf2af7 which fixes the problem? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1796520 Title: autogen crashes on qemu-sh4-user after 61dedf2af7 Status in QEMU: New Bug description: Running "autogen --help" crashes on qemu-sh4-user with: (sid-sh4-sbuild)root@nofan:/# autogen --help Unhandled trap: 0x180 pc=0xf64dd2de sr=0x pr=0xf63b9c74 fpscr=0x0008 spc=0x ssr=0x gbr=0xf61102a8 vbr=0x sgr=0x dbr=0x delayed_pc=0xf64dd2a0 fpul=0x0003 r0=0xf6fc1320 r1=0x r2=0x5dc4 r3=0xf67bfb50 r4=0xf6fc1230 r5=0xf6fc141c r6=0x03ff r7=0x r8=0x0004 r9=0xf63e20bc r10=0xf6fc141c r11=0xf63e28f0 r12=0xf63e2258 r13=0xf63eae1c r14=0x0804 r15=0xf6fc1220 r16=0x r17=0x r18=0x r19=0x r20=0x r21=0x r22=0x r23=0x (sid-sh4-sbuild)root@nofan:/# Bi-secting found this commit to be the culprit: 61dedf2af79fb5866dc7a0f972093682f2185e17 is the first bad commit commit 61dedf2af79fb5866dc7a0f972093682f2185e17 Author: Richard Henderson Date: Tue Jul 18 10:02:50 2017 -1000 target/sh4: Add missing FPSCR.PR == 0 checks Both frchg and fschg require PR == 0, otherwise undefined_operation. Reviewed-by: Aurelien Jarno Signed-off-by: Richard Henderson Message-Id: <20170718200255.31647-26-...@twiddle.net> Signed-off-by: Aurelien Jarno :04 04 980d79b69ae712f23a1e4c56983e97a843153b4a 1024c109f506c7ad57367c63bc8bbbc8a7a36cd7 M target Reverting 61dedf2af79fb5866dc7a0f972093682f2185e17 fixes the problem for me. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1796520/+subscriptions
[Qemu-devel] bochs-display and the future of VGA support
Hi! I just happened to read Gerd Hoffmann's post on the bochs-display [1] driver and was wondering what the future plans for VGA support are. Phoronix makes it sound like [2] that VGA support for guests is supposed to be removed which I find hard to believe. Since once VGA support is gone, QEMU would no longer be able to run older operating systems which is one of the key features of an emulator in my opinion. Can anyone tell me what the plans are? PS: I'm subscribed to the list, but currently don't receive any mailing list mail due to the high volume. So please CC me in your reply. Thanks, Adrian > [1] https://www.kraxel.org/blog/2018/10/qemu-vga-emulation-and-bochs-display/ > [2] > https://www.phoronix.com/scan.php?page=news_item=QEMU-Legacy-Free-Display -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[Qemu-devel] [Bug 1796520] [NEW] autogen crashes on qemu-sh4-user after 61dedf2af7
Public bug reported: Running "autogen --help" crashes on qemu-sh4-user with: (sid-sh4-sbuild)root@nofan:/# autogen --help Unhandled trap: 0x180 pc=0xf64dd2de sr=0x pr=0xf63b9c74 fpscr=0x0008 spc=0x ssr=0x gbr=0xf61102a8 vbr=0x sgr=0x dbr=0x delayed_pc=0xf64dd2a0 fpul=0x0003 r0=0xf6fc1320 r1=0x r2=0x5dc4 r3=0xf67bfb50 r4=0xf6fc1230 r5=0xf6fc141c r6=0x03ff r7=0x r8=0x0004 r9=0xf63e20bc r10=0xf6fc141c r11=0xf63e28f0 r12=0xf63e2258 r13=0xf63eae1c r14=0x0804 r15=0xf6fc1220 r16=0x r17=0x r18=0x r19=0x r20=0x r21=0x r22=0x r23=0x (sid-sh4-sbuild)root@nofan:/# Bi-secting found this commit to be the culprit: 61dedf2af79fb5866dc7a0f972093682f2185e17 is the first bad commit commit 61dedf2af79fb5866dc7a0f972093682f2185e17 Author: Richard Henderson Date: Tue Jul 18 10:02:50 2017 -1000 target/sh4: Add missing FPSCR.PR == 0 checks Both frchg and fschg require PR == 0, otherwise undefined_operation. Reviewed-by: Aurelien Jarno Signed-off-by: Richard Henderson Message-Id: <20170718200255.31647-26-...@twiddle.net> Signed-off-by: Aurelien Jarno :04 04 980d79b69ae712f23a1e4c56983e97a843153b4a 1024c109f506c7ad57367c63bc8bbbc8a7a36cd7 M target Reverting 61dedf2af79fb5866dc7a0f972093682f2185e17 fixes the problem for me. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1796520 Title: autogen crashes on qemu-sh4-user after 61dedf2af7 Status in QEMU: New Bug description: Running "autogen --help" crashes on qemu-sh4-user with: (sid-sh4-sbuild)root@nofan:/# autogen --help Unhandled trap: 0x180 pc=0xf64dd2de sr=0x pr=0xf63b9c74 fpscr=0x0008 spc=0x ssr=0x gbr=0xf61102a8 vbr=0x sgr=0x dbr=0x delayed_pc=0xf64dd2a0 fpul=0x0003 r0=0xf6fc1320 r1=0x r2=0x5dc4 r3=0xf67bfb50 r4=0xf6fc1230 r5=0xf6fc141c r6=0x03ff r7=0x r8=0x0004 r9=0xf63e20bc r10=0xf6fc141c r11=0xf63e28f0 r12=0xf63e2258 r13=0xf63eae1c r14=0x0804 r15=0xf6fc1220 r16=0x r17=0x r18=0x r19=0x r20=0x r21=0x r22=0x r23=0x (sid-sh4-sbuild)root@nofan:/# Bi-secting found this commit to be the culprit: 61dedf2af79fb5866dc7a0f972093682f2185e17 is the first bad commit commit 61dedf2af79fb5866dc7a0f972093682f2185e17 Author: Richard Henderson Date: Tue Jul 18 10:02:50 2017 -1000 target/sh4: Add missing FPSCR.PR == 0 checks Both frchg and fschg require PR == 0, otherwise undefined_operation. Reviewed-by: Aurelien Jarno Signed-off-by: Richard Henderson Message-Id: <20170718200255.31647-26-...@twiddle.net> Signed-off-by: Aurelien Jarno :04 04 980d79b69ae712f23a1e4c56983e97a843153b4a 1024c109f506c7ad57367c63bc8bbbc8a7a36cd7 M target Reverting 61dedf2af79fb5866dc7a0f972093682f2185e17 fixes the problem for me. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1796520/+subscriptions
Re: [Qemu-devel] [PATCH v2] sh4: fix use_icount with linux-user
On 08/11/2018 10:23 AM, Laurent Vivier wrote:
> This fixes java in a linux-user chroot:
> $ java --version
> qemu-sh4: .../accel/tcg/cpu-exec.c:634: cpu_loop_exec_tb: Assertion
> `use_icount' failed.
> qemu: uncaught target signal 6 (Aborted) - core dumped
> Aborted (core dumped)
>
> In gen_conditional_jump() in the GUSA_EXCLUSIVE part, we must reset
> base.is_jmp to DISAS_NEXT after the gen_goto_tb() as it is done in
> gen_delayed_conditional_jump() after the gen_jump().
>
> Bug: https://bugs.launchpad.net/qemu/+bug/1768246
> Fixes: 4834871bc95b67343248100e2a75ae0d287bc08b
>("target/sh4: Convert to DisasJumpType")
> Reported-by: John Paul Adrian Glaubitz
> Signed-off-by: Laurent Vivier
Thanks, testing this revision now as well.
Both patches finally allow me to use much newer QEMU versions for SH4,
before that I was stuck to versions from before the regression was
introduced.
So far, the overall improvement is quite spectacular and even the
Haskell compiler GHC now works much more reliable on qemu-sh4 than
it did in the past.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Qemu-devel] [PATCH] sh4: fix use_icount with linux-user
On 08/11/2018 12:25 AM, Laurent Vivier wrote: > This patch revert changes from 4834871bc9 that are > not only state renaming. > > This fixes java in a linux-user chroot: > $ java --version > qemu-sh4: .../accel/tcg/cpu-exec.c:634: cpu_loop_exec_tb: Assertion > `use_icount' failed. > qemu: uncaught target signal 6 (Aborted) - core dumped > Aborted (core dumped) > > The problem seems to be in gen_conditional_jump() in the > GUSA_EXCLUSIVE part: it should reset base.is_jmp to DISAS_NEXT after the > gen_goto_tb() as it is done in gen_delayed_conditional_jump() after the > gen_jump(). Fantastic, this fixes it! Can we get this into 3.0.0 before release? Tested-by: John Paul Adrian Glaubitz -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[Qemu-devel] [Bug 1768246] Re: cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed.
Still present on git master: /usr/bin/make -f src/server/CMakeFiles/KF5WaylandServer_autogen.dir/build.make src/server/CMakeFiles/KF5WaylandServer_autogen.dir/build make[3]: Entering directory '/<>/obj-sh4-linux-gnu' make[3]: Entering directory '/<>/obj-sh4-linux-gnu' [ 0%] Automatic MOC for target surfaceExtensionHelper [ 0%] Generating src/KF5Wayland.qch, src/KF5Wayland.tags cd /<>/obj-sh4-linux-gnu/autotests/server && /usr/bin/cmake -E cmake_autogen /<>/obj-sh4-linux-gnu/autotests/server/CMakeFiles/surfaceExtensionHelper_autogen.dir/AutogenInfo.cmake Debian cd /<>/obj-sh4-linux-gnu/src && cmake -E remove_directory "/<>/obj-sh4-linux-gnu/src/KF5Wayland_ECMQchDoxygen" [ 0%] Automatic MOC for target KF5WaylandClient [ 0%] Automatic MOC for target kwaylandScanner cd /<>/obj-sh4-linux-gnu/src/tools && /usr/bin/cmake -E cmake_autogen /<>/obj-sh4-linux-gnu/src/tools/CMakeFiles/kwaylandScanner_autogen.dir/AutogenInfo.cmake Debian cd /<>/obj-sh4-linux-gnu/src/client && /usr/bin/cmake -E cmake_autogen /<>/obj-sh4-linux-gnu/src/client/CMakeFiles/KF5WaylandClient_autogen.dir/AutogenInfo.cmake Debian [ 0%] Automatic MOC for target KF5WaylandServer cd /<>/obj-sh4-linux-gnu/src/server && /usr/bin/cmake -E cmake_autogen /<>/obj-sh4-linux-gnu/src/server/CMakeFiles/KF5WaylandServer_autogen.dir/AutogenInfo.cmake Debian cd /<>/obj-sh4-linux-gnu/src && cmake -E make_directory "/<>/obj-sh4-linux-gnu/src/KF5Wayland_ECMQchDoxygen" qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:634: cpu_loop_exec_tb: Assertion `use_icount' failed. qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault make[3]: *** [autotests/server/CMakeFiles/surfaceExtensionHelper_autogen.dir/build.make:61: autotests/server/CMakeFiles/surfaceExtensionHelper_autogen] Error 139 make[3]: Leaving directory '/<>/obj-sh4-linux-gnu' make[2]: *** [CMakeFiles/Makefile2:3729: autotests/server/CMakeFiles/surfaceExtensionHelper_autogen.dir/all] Error 2 make[2]: *** Waiting for unfinished jobs qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:634: cpu_loop_exec_tb: Assertion `use_icount' failed. qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault make[3]: *** [src/client/CMakeFiles/KF5WaylandClient_autogen.dir/build.make:61: src/client/CMakeFiles/KF5WaylandClient_autogen] Error 139 make[3]: Leaving directory '/<>/obj-sh4-linux-gnu' make[2]: *** [CMakeFiles/Makefile2:259: src/client/CMakeFiles/KF5WaylandClient_autogen.dir/all] Error 2 cd /<>/obj-sh4-linux-gnu/src && /usr/bin/doxygen /<>/obj-sh4-linux-gnu/src/KF5Wayland_ECMQchDoxygen.config qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:634: cpu_loop_exec_tb: Assertion `use_icount' failed. qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault make[3]: *** [src/tools/CMakeFiles/kwaylandScanner_autogen.dir/build.make:61: src/tools/CMakeFiles/kwaylandScanner_autogen] Error 139 make[3]: Leaving directory '/<>/obj-sh4-linux-gnu' make[2]: *** [CMakeFiles/Makefile2:437: src/tools/CMakeFiles/kwaylandScanner_autogen.dir/all] Error 2 qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:634: cpu_loop_exec_tb: Assertion `use_icount' failed. qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault make[3]: *** [src/server/CMakeFiles/KF5WaylandServer_autogen.dir/build.make:61: src/server/CMakeFiles/KF5WaylandServer_autogen] Error 139 make[3]: Leaving directory '/<>/obj-sh4-linux-gnu' make[2]: *** [CMakeFiles/Makefile2:347: src/server/CMakeFiles/KF5WaylandServer_autogen.dir/all] Error 2 QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-glaubitz' Building up file structure... Insert custom filters... Insert help data for filter section (1 of 1)... Insert files... Warning: The file /<>/obj-sh4-linux-gnu/src/KF5Wayland_ECMQchDoxygen/html/dynsections.js does not exist, skipping it... Insert contents... -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1768246 Title: cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. Status in QEMU: New Bug description: OpenJDK no longer works on qemu-sh4, it previously did after #1735384 was fixed. Crash indicates an assertion failure: (sid-sh4-sbuild)root@nofan:/# java --version qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. qemu: uncaught target signal 6 (Aborted) - core dumped Aborted (sid-sh4-sbuild)root@nofan:/# Haven't bi-sected the issue yet, but will do so later. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1768246/+subscriptions
[Qemu-devel] [Bug 1777226] [NEW] qemu-user warnings confuse userland applications
Public bug reported: I recently observed that warning messages emitted by qemu-user can confuse applications when reading from stdout/stderr. This was observed with the configure script of OpenJDK-11 on qemu-sh4: configure: Found potential Boot JDK using configure arguments configure: Potential Boot JDK found at /usr/lib/jvm/java-10-openjdk-sh4 is incorrect JDK version (qemu: Unsupported syscall: 318); ignoring configure: (Your Boot JDK version must be one of: 10 11) configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK configure exiting with result code 1 See: https://buildd.debian.org/status/fetch.php?pkg=openjdk-11=sh4=11%7E18-1=1529119043=0 Commenting out the line of code which emits the warning fixes the problem for me and the configure script finishes without problems. Thus, qemu should be modified to avoid cluttering stdout or stderr with its own messages and rather send those warnings to a log file or similar. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1777226 Title: qemu-user warnings confuse userland applications Status in QEMU: New Bug description: I recently observed that warning messages emitted by qemu-user can confuse applications when reading from stdout/stderr. This was observed with the configure script of OpenJDK-11 on qemu-sh4: configure: Found potential Boot JDK using configure arguments configure: Potential Boot JDK found at /usr/lib/jvm/java-10-openjdk-sh4 is incorrect JDK version (qemu: Unsupported syscall: 318); ignoring configure: (Your Boot JDK version must be one of: 10 11) configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK configure exiting with result code 1 See: https://buildd.debian.org/status/fetch.php?pkg=openjdk-11=sh4=11%7E18-1=1529119043=0 Commenting out the line of code which emits the warning fixes the problem for me and the configure script finishes without problems. Thus, qemu should be modified to avoid cluttering stdout or stderr with its own messages and rather send those warnings to a log file or similar. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1777226/+subscriptions
Re: [Qemu-devel] [Bug 1768246] [NEW] cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed.
This bug also affects GHC on qemu-sh4:
checking version of ghc... ./configure: line 3199: 55879 Segmentation fault
"${WithGhc-ghc}" --version > conftestghc 2>&1
8.2.2
qemu-sh4-static: /build/qemu-fWXVPw/qemu-2.12+dfsg/accel/tcg/cpu-exec.c:648:
cpu_loop_exec_tb: Assertion `use_icount' failed.
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
qemu-sh4-static: /build/qemu-fWXVPw/qemu-2.12+dfsg/accel/tcg/cpu-exec.c:648:
cpu_loop_exec_tb: Assertion `use_icount' failed.
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
qemu-sh4-static: /build/qemu-fWXVPw/qemu-2.12+dfsg/accel/tcg/cpu-exec.c:648:
cpu_loop_exec_tb: Assertion `use_icount' failed.
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
qemu-sh4-static: /build/qemu-fWXVPw/qemu-2.12+dfsg/accel/tcg/cpu-exec.c:648:
cpu_loop_exec_tb: Assertion `use_icount' failed.
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
qemu-sh4-static: /build/qemu-fWXVPw/qemu-2.12+dfsg/accel/tcg/cpu-exec.c:648:
cpu_loop_exec_tb: Assertion `use_icount' failed.
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Just tested with qemu 5a5c383b1373aeb6c87a0d6060f6c3dc7c53082b.
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1768246
Title:
cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed.
Status in QEMU:
New
Bug description:
OpenJDK no longer works on qemu-sh4, it previously did after #1735384
was fixed.
Crash indicates an assertion failure:
(sid-sh4-sbuild)root@nofan:/# java --version
qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb:
Assertion `use_icount' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted
(sid-sh4-sbuild)root@nofan:/#
Haven't bi-sected the issue yet, but will do so later.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1768246/+subscriptions
Re: [Qemu-devel] [Bug 1768246] [NEW] cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed.
On 05/01/2018 05:31 PM, Alex Bennée wrote: >> Haven't bi-sected the issue yet, but will do so later. > > Hmm that's ominous - arguably the assert should be inside the > CONFIG_USER but I'm not sure how you get to the point where icount isn't > < 0 after receiving a TB_EXIT_REQUESTED. git bisect yielded this: 4834871bc95b67343248100e2a75ae0d287bc08b is the first bad commit commit 4834871bc95b67343248100e2a75ae0d287bc08b Author: Richard Henderson <r...@twiddle.net> Date: Thu Sep 7 11:50:54 2017 -0700 target/sh4: Convert to DisasJumpType Signed-off-by: Richard Henderson <r...@twiddle.net> Message-Id: <20170907185057.23421-3-richard.hender...@linaro.org> [aurel32: fix whitespace] Signed-off-by: Aurelien Jarno <aurel...@aurel32.net> :04 04 6e0e67cc5d0eb5ef461510d314c6af43eecc08bb aa3399c893c49e6fafda157181cf10f8fbcd0a72 M target -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1768246 Title: cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. Status in QEMU: New Bug description: OpenJDK no longer works on qemu-sh4, it previously did after #1735384 was fixed. Crash indicates an assertion failure: (sid-sh4-sbuild)root@nofan:/# java --version qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. qemu: uncaught target signal 6 (Aborted) - core dumped Aborted (sid-sh4-sbuild)root@nofan:/# Haven't bi-sected the issue yet, but will do so later. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1768246/+subscriptions
[Qemu-devel] [Bug 1768246] [NEW] cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed.
Public bug reported: OpenJDK no longer works on qemu-sh4, it previously did after #1735384 was fixed. Crash indicates an assertion failure: (sid-sh4-sbuild)root@nofan:/# java --version qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. qemu: uncaught target signal 6 (Aborted) - core dumped Aborted (sid-sh4-sbuild)root@nofan:/# Haven't bi-sected the issue yet, but will do so later. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1768246 Title: cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. Status in QEMU: New Bug description: OpenJDK no longer works on qemu-sh4, it previously did after #1735384 was fixed. Crash indicates an assertion failure: (sid-sh4-sbuild)root@nofan:/# java --version qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. qemu: uncaught target signal 6 (Aborted) - core dumped Aborted (sid-sh4-sbuild)root@nofan:/# Haven't bi-sected the issue yet, but will do so later. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1768246/+subscriptions
[Qemu-devel] [Bug 1738545] [NEW] Go binaries panic with "mmap errno 9" on qemu-user
Public bug reported:
Go binaries panic with "mmap errno 9" on qemu-user.
root@nofan:/# cat hello.go
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
root@nofan:/# gccgo-7 hello.go -o hello
root@nofan:/# ./hello
mmap errno 9
fatal error: mmap
runtime stack:
mmap errno 9
fatal error: mmap
panic during panic
runtime stack:
mmap errno 9
fatal error: mmap
stack trace unavailable
root@nofan:/#
Tested with qemu from git master with Debian unstable for armel.
Same binaries work fine on real hardware.
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1738545
Title:
Go binaries panic with "mmap errno 9" on qemu-user
Status in QEMU:
New
Bug description:
Go binaries panic with "mmap errno 9" on qemu-user.
root@nofan:/# cat hello.go
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
root@nofan:/# gccgo-7 hello.go -o hello
root@nofan:/# ./hello
mmap errno 9
fatal error: mmap
runtime stack:
mmap errno 9
fatal error: mmap
panic during panic
runtime stack:
mmap errno 9
fatal error: mmap
stack trace unavailable
root@nofan:/#
Tested with qemu from git master with Debian unstable for armel.
Same binaries work fine on real hardware.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1738545/+subscriptions
[Qemu-devel] [Bug 1696353] Re: golang binaries fail to start under linux-user
I just gave it a test with qemu-arm and Go binaries still crash for me,
albeit differently:
root@nofan:/# cat hello.go
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
root@nofan:/# gccgo-7 hello.go -o hello
root@nofan:/# ./hello
mmap errno 9
fatal error: mmap
runtime stack:
mmap errno 9
fatal error: mmap
panic during panic
runtime stack:
mmap errno 9
fatal error: mmap
stack trace unavailable
root@nofan:/#
Should I file a new bug report?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1696353
Title:
golang binaries fail to start under linux-user
Status in QEMU:
Won't Fix
Bug description:
With current master golang binaries fail when run under linux-user,
for example:
[will@localhost qemu]$ ./arm-linux-user/qemu-arm glide
runtime: failed to create new OS thread (have 2 already; errno=22)
fatal error: newosproc
runtime stack:
runtime.throw(0x45f879, 0x9)
/usr/lib/golang/src/runtime/panic.go:566 +0x78
runtime.newosproc(0x1092c000, 0x1093bfe0)
/usr/lib/golang/src/runtime/os_linux.go:160 +0x1b0
runtime.newm(0x4ae1e8, 0x0)
/usr/lib/golang/src/runtime/proc.go:1572 +0x12c
runtime.main.func1()
/usr/lib/golang/src/runtime/proc.go:126 +0x24
runtime.systemstack(0x5ef900)
/usr/lib/golang/src/runtime/asm_arm.s:247 +0x80
runtime.mstart()
/usr/lib/golang/src/runtime/proc.go:1079
goroutine 1 [running]:
runtime.systemstack_switch()
/usr/lib/golang/src/runtime/asm_arm.s:192 +0x4 fp=0x109287ac
sp=0x109287a8
runtime.main()
/usr/lib/golang/src/runtime/proc.go:127 +0x5c fp=0x109287d4
sp=0x109287ac
runtime.goexit()
/usr/lib/golang/src/runtime/asm_arm.s:998 +0x4 fp=0x109287d4
sp=0x109287d4
The reason for this is that the golang runtime does not pass the
CLONE_SYSVMEM flag to clone so the clone flags checks fail:
https://github.com/golang/go/blob/master/src/runtime/os_linux.go#L155
The attached patch allows golang binaries to start under linux-user.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1696353/+subscriptions
[Qemu-devel] [Bug 1737444] [NEW] gccgo setcontext conftest crashes qemu-sh4
Public bug reported:
While testing gccgo on sh4 to add SH platform definitions to libgo, I
discovered that the following conftest program which is part of the
libgo configure script crashes on qemu-sh4:
(sid-sh4-sbuild)root@z6:/# cat setcontext.c
#include
#include
#include
#include
__thread int tls;
static char stack[10 * 1024 * 1024];
static ucontext_t c;
/* Called via makecontext/setcontext. */
static void
cfn (void)
{
exit (tls);
}
/* Called via pthread_create. */
static void *
tfn (void *dummy)
{
/* The thread should still see this value after calling
setcontext. */
tls = 0;
setcontext ();
/* The call to setcontext should not return. */
abort ();
}
int
main ()
{
pthread_t tid;
/* The thread should not see this value. */
tls = 1;
if (getcontext () < 0)
abort ();
c.uc_stack.ss_sp = stack;
#ifdef MAKECONTEXT_STACK_TOP
c.uc_stack.ss_sp += sizeof stack;
#endif
c.uc_stack.ss_flags = 0;
c.uc_stack.ss_size = sizeof stack;
c.uc_link = NULL;
makecontext (, cfn, 0);
if (pthread_create (, NULL, tfn, NULL) != 0)
abort ();
if (pthread_join (tid, NULL) != 0)
abort ();
/* The thread should have called exit. */
abort ();
}
(sid-sh4-sbuild)root@z6:/# gcc -o setcontext -lpthread setcontext.c
(sid-sh4-sbuild)root@z6:/# ./setcontext
Unhandled trap: 0x180
pc=0x7f69235e sr=0x pr=0x00400710 fpscr=0x0008
spc=0x ssr=0x gbr=0x7f658478 vbr=0x
sgr=0x dbr=0x delayed_pc=0x7f692320 fpul=0x
r0=0x00e11158 r1=0x r2=0x0001 r3=0x72e0
r4=0x00e11068 r5=0x7314 r6=0x731c r7=0x
r8=0x004007b0 r9=0x r10=0x r11=0x
r12=0x7f79ac54 r13=0x r14=0x7288 r15=0x7288
r16=0x r17=0x r18=0x r19=0x
r20=0x r21=0x r22=0x r23=0x
(sid-sh4-sbuild)root@z6:/#
The same code works fine on my Renesas SH7785LCR evaluation board:
root@tirpitz:~> uname -a
Linux tirpitz 3.16.7-ckt7 #8 PREEMPT Fri Oct 21 18:47:41 CEST 2016 sh4a
GNU/Linux
root@tirpitz:~> gcc -o setcontext setcontext.c -lpthread
root@tirpitz:~> ./setcontext
root@tirpitz:~> echo $?
0
root@tirpitz:~>
Due to this bug, it is not possible to compile gcc-7 with the Go
frontend enabled on qemu-sh4.
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1737444
Title:
gccgo setcontext conftest crashes qemu-sh4
Status in QEMU:
New
Bug description:
While testing gccgo on sh4 to add SH platform definitions to libgo, I
discovered that the following conftest program which is part of the
libgo configure script crashes on qemu-sh4:
(sid-sh4-sbuild)root@z6:/# cat setcontext.c
#include
#include
#include
Re: [Qemu-devel] [Bug 1735384] [RFC PATCH] target/sh4/translate.c: fix TCG leak during gusa sequence
On 12/06/2017 11:52 AM, Alex Bennée wrote: >> Wow, thanks! I wanted to run your suggested test today as I ran out of >> time yesterday and now you already fixed it :-). > > Can you confirm you've tested it and your happy it works? I already confirmed it, but in case my previous mail got lost: Tested-by: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> And, yes, I'm happy it works :-). Can now switch back to using the latest qemu snapshot for building packages for Debian sh4. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1735384 Title: OpenJDK JVM segfaults on qemu-sh4 (regression) Status in QEMU: New Bug description: Some of the recent changes introduced a regression which makes the OpenJDK JVM crash on qemu-sh4: (sid-sh4-sbuild)root@nofan:/# java -version qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (sid-sh4-sbuild)root@nofan:/# An older version works fine: (sid-sh4-sbuild)root@nofan:/# java -version openjdk version "9.0.1" OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) (sid-sh4-sbuild)root@nofan:/# Haven't had time for bisecting this yet. Adrian To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1735384/+subscriptions
Re: [Qemu-devel] [Bug 1735384] [RFC PATCH] target/sh4/translate.c: fix TCG leak during gusa sequence
On 12/06/2017 10:30 AM, Alex Bennée wrote: > This fixes bug #1735384 while running java under qemu-sh4. When debug > was enabled it showed a problem with TCG temps. Once fixed I was able > to run java -version normally. > > Reported-by: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> > Suggested-by: Richard Henderson <richard.hender...@linaro.org> > Signed-off-by: Alex Bennée <alex.ben...@linaro.org> I can confirm that this fixes the issue for me, too. So, just in case: Tested-by: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1735384 Title: OpenJDK JVM segfaults on qemu-sh4 (regression) Status in QEMU: New Bug description: Some of the recent changes introduced a regression which makes the OpenJDK JVM crash on qemu-sh4: (sid-sh4-sbuild)root@nofan:/# java -version qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (sid-sh4-sbuild)root@nofan:/# An older version works fine: (sid-sh4-sbuild)root@nofan:/# java -version openjdk version "9.0.1" OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) (sid-sh4-sbuild)root@nofan:/# Haven't had time for bisecting this yet. Adrian To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1735384/+subscriptions
Re: [Qemu-devel] [Bug 1735384] [RFC PATCH] target/sh4/translate.c: fix TCG leak during gusa sequence
Hi Alex!
Wow, thanks! I wanted to run your suggested test today as I ran out of
time yesterday and now you already fixed it :-).
Thanks a lot!
Adrian
> On Dec 6, 2017, at 10:30 AM, Alex Bennée <alex.ben...@linaro.org> wrote:
>
> This fixes bug #1735384 while running java under qemu-sh4. When debug
> was enabled it showed a problem with TCG temps. Once fixed I was able
> to run java -version normally.
>
> Reported-by: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
> Suggested-by: Richard Henderson <richard.hender...@linaro.org>
> Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
> ---
> target/sh4/translate.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/sh4/translate.c b/target/sh4/translate.c
> index 703020fe87..b4b5c822d0 100644
> --- a/target/sh4/translate.c
> +++ b/target/sh4/translate.c
> @@ -2189,7 +2189,7 @@ static int decode_gusa(DisasContext *ctx, CPUSH4State
> *env, int *pmax_insns)
> }
>
> /* If op_src is not a valid register, then op_arg was a constant. */
> -if (op_src < 0) {
> +if (op_src < 0 && !TCGV_IS_UNUSED(op_arg)) {
> tcg_temp_free_i32(op_arg);
> }
>
> --
> 2.15.1
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1735384
>
> Title:
> OpenJDK JVM segfaults on qemu-sh4 (regression)
>
> Status in QEMU:
> New
>
> Bug description:
> Some of the recent changes introduced a regression which makes the
> OpenJDK JVM crash on qemu-sh4:
>
> (sid-sh4-sbuild)root@nofan:/# java -version
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault
> (sid-sh4-sbuild)root@nofan:/#
>
> An older version works fine:
>
> (sid-sh4-sbuild)root@nofan:/# java -version
> openjdk version "9.0.1"
> OpenJDK Runtime Environment (build 9.0.1+11-Debian-1)
> OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode)
> (sid-sh4-sbuild)root@nofan:/#
>
> Haven't had time for bisecting this yet.
>
> Adrian
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1735384/+subscriptions
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1735384
Title:
OpenJDK JVM segfaults on qemu-sh4 (regression)
Status in QEMU:
New
Bug description:
Some of the recent changes introduced a regression which makes the
OpenJDK JVM crash on qemu-sh4:
(sid-sh4-sbuild)root@nofan:/# java -version
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
(sid-sh4-sbuild)root@nofan:/#
An older version works fine:
(sid-sh4-sbuild)root@nofan:/# java -version
openjdk version "9.0.1"
OpenJDK Runtime Environment (build 9.0.1+11-Debian-1)
OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode)
(sid-sh4-sbuild)root@nofan:/#
Haven't had time for bisecting this yet.
Adrian
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1735384/+subscriptions
Re: [Qemu-devel] [Bug 1735384] [NEW] OpenJDK JVM segfaults on qemu-sh4 (regression)
On 12/05/2017 04:02 PM, Alex Bennée wrote: > With an --enable-debug build I managed to replicate: > >root@6e10336e48ac:/etc/apt# java --version >qemu-sh4: /home/alex/lsrc/qemu/qemu.git/tcg/tcg.h:703: temp_idx: Assertion > `n >= 0 && n < tcg_ctx->nb_temps' failed. >qemu: uncaught target signal 11 (Segmentation fault) - core dumped >Segmentation fault (core dumped) > > Which implies the front end has gotten something wrong. Maybe this > somehow tripped up the fault resolution in the end? Can you try with an > --enable-debug build? Will do. Thank you for giving me a heads-up! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1735384 Title: OpenJDK JVM segfaults on qemu-sh4 (regression) Status in QEMU: New Bug description: Some of the recent changes introduced a regression which makes the OpenJDK JVM crash on qemu-sh4: (sid-sh4-sbuild)root@nofan:/# java -version qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (sid-sh4-sbuild)root@nofan:/# An older version works fine: (sid-sh4-sbuild)root@nofan:/# java -version openjdk version "9.0.1" OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) (sid-sh4-sbuild)root@nofan:/# Haven't had time for bisecting this yet. Adrian To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1735384/+subscriptions
Re: [Qemu-devel] [Bug 1735384] Re: OpenJDK JVM segfaults on qemu-sh4 (regression)
On 12/04/2017 10:29 AM, Alex Bennée wrote:
> It's hard to imagine a scenario where taking the tb_lock() for resolving
> something that will fail is going to be an improvement. However maybe
> there is a subtle difference with sh4's javavm implementation.
So, OpenJDK doesn't have a SH-specific implementation of the JVM, it just
uses the Zero variant, which is a pure C++ implementation of the JVM.
The same implementation is used on any other architecture like older ARM
(< ARMv7). I just tested it on ARMv4T and it doesn't crash there on
qemu-user.
However, SH4 is special due to its implementation of atomics in user
space called gUSA for which support to qemu-user has been recently
added by Richard Hendersson. Maybe the problem lies there.
> A backtrace QEMU after the segv would be useful here.
I forgot what the proper procedure is for running qemu-user inside
GDB. Could you help me with that?
The strace looks like this in any case:
28856 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory)
28856 open("/lib/sh4-linux-gnu/libgcc_s.so.1",O_RDONLY|O_CLOEXEC) = 3
28856 read(3,0x7fffacd4,512) = 512
28856 fstat64(3,0x7fffabe8) = 0
28856 mmap(NULL,189084,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) =
0x7ee27000
28856 mprotect(0x7ee45000,61440,PROT_NONE) = 0
28856
mmap(0x7ee54000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1d000)
= 0x7ee54000
28856 close(3) = 0
28856 mprotect(0x7ee54000,4096,PROT_READ) = 0
28856 mprotect(0x7eee8000,4096,PROT_READ) = 0
28856 mprotect(0x7f05c000,20480,PROT_READ) = 0
28856 mprotect(0x7f5c8000,53248,PROT_READ) = 0
28856 getpid() = 28856
28856 munmap(0x7f065000,50134) = 0
28856 getpid() = 28856
28856
mmap(NULL,1572864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|0x2,-1,0)
= 0x7eca7000
28856 mprotect(0x7eca7000,4096,PROT_NONE) = 0
28856
clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7ee26048,parent_tidptr=0x7ee26528,tls=0x7ee26930,child_tidptr=0x7ee26528)
= 28860
28856 futex(0x7ee26528,FUTEX_WAIT,28860,NULL,0x7f77c6e8,2138556136)28856
set_robust_list(2128766256,12,-1,2128766652,-1,2128764832) = -1 errno=38
(Function not implemented)
--- SIGSEGV {si_signo=SIGSEGV, si_code=1, si_addr=0x289da000} ---
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
(sid-sh4-sbuild)root@nofan:/local_scratch/sid-sh4-sbuild#
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1735384
Title:
OpenJDK JVM segfaults on qemu-sh4 (regression)
Status in QEMU:
New
Bug description:
Some of the recent changes introduced a regression which makes the
OpenJDK JVM crash on qemu-sh4:
(sid-sh4-sbuild)root@nofan:/# java -version
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
(sid-sh4-sbuild)root@nofan:/#
An older version works fine:
(sid-sh4-sbuild)root@nofan:/# java -version
openjdk version "9.0.1"
OpenJDK Runtime Environment (build 9.0.1+11-Debian-1)
OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode)
(sid-sh4-sbuild)root@nofan:/#
Haven't had time for bisecting this yet.
Adrian
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1735384/+subscriptions
[Qemu-devel] [Bug 1673976] Re: linux-user clone() can't handle glibc posix_spawn() (causes locale-gen to assert)
I have verified that this patch [1] in glibc_2.25 and glibc_2.26 fixes the assert. > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=22273 ** Bug watch added: Sourceware.org Bugzilla #22273 https://sourceware.org/bugzilla/show_bug.cgi?id=22273 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1673976 Title: linux-user clone() can't handle glibc posix_spawn() (causes locale-gen to assert) Status in QEMU: New Bug description: I'm running a command (locale-gen) inside of an armv7h chroot mounted on my x86_64 desktop by putting qemu-arm-static into /usr/bin/ of the chroot file system and I get a core dump. locale-gen Generating locales... en_US.UTF-8...localedef: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0' failed. qemu: uncaught target signal 6 (Aborted) - core dumped /usr/bin/locale-gen: line 41:34 Aborted (core dumped) localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias $locale I've done this same thing successfully for years, but this breakage has appeared some time in the last 3 or so months. Possibly with the update to qemu version 2.8. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1673976/+subscriptions
Re: [Qemu-devel] [Bug 1735384] Re: OpenJDK JVM segfaults on qemu-sh4 (regression)
The offending commit is: d25f2a72272b9ffe0d06710d6217d1169bc2cc7d is the first bad commit commit d25f2a72272b9ffe0d06710d6217d1169bc2cc7d Author: Alex Bennée <alex.ben...@linaro.org> Date: Mon Nov 13 13:55:27 2017 + accel/tcg/translate-all: expand cpu_restore_state addr check We are still seeing signals during translation time when we walk over a page protection boundary. This expands the check to ensure the host PC is inside the code generation buffer. The original suggestion was to check versus tcg_ctx.code_gen_ptr but as we now segment the translation buffer we have to settle for just a general check for being inside. I've also fixed up the declaration to make it clear it can deal with invalid addresses. A later patch will fix up the call sites. Signed-off-by: Alex Bennée <alex.ben...@linaro.org> Reported-by: Peter Maydell <peter.mayd...@linaro.org> Reviewed-by: Laurent Vivier <laur...@vivier.eu> Reviewed-by: Richard Henderson <richard.hender...@linaro.org> Message-id: 20171108153245.20740-2-alex.ben...@linaro.org Suggested-by: Paolo Bonzini <pbonz...@redhat.com> Cc: Richard Henderson <r...@twiddle.net> Tested-by: Peter Maydell <peter.mayd...@linaro.org> Signed-off-by: Peter Maydell <peter.mayd...@linaro.org> :04 04 da50c4c43089d3ee7d1e9ad50d3c9036114e5f11 cd6a0dcaa1d284fe5439f6f3b61547d4b0662768 M accel :04 04 c294a7c102d27295f8d81cc06b5d4d17357440ad 5a1268b7634f69f0806f22161ec7d6a1a26c8812 M include Reverting the commit resolves the issue. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1735384 Title: OpenJDK JVM segfaults on qemu-sh4 (regression) Status in QEMU: New Bug description: Some of the recent changes introduced a regression which makes the OpenJDK JVM crash on qemu-sh4: (sid-sh4-sbuild)root@nofan:/# java -version qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (sid-sh4-sbuild)root@nofan:/# An older version works fine: (sid-sh4-sbuild)root@nofan:/# java -version openjdk version "9.0.1" OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) (sid-sh4-sbuild)root@nofan:/# Haven't had time for bisecting this yet. Adrian To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1735384/+subscriptions
Re: [Qemu-devel] /usr/bin/m4: internal error detected
Hi Florian! On 12/01/2017 11:40 AM, Florian Weimer wrote: Is this <https://sourceware.org/bugzilla/show_bug.cgi?id=22273>? If yes, it should be fixed in master and on the 2.25 and 2.26 branches. 2.24 and earlier should not be affected. You're right, this is indeed fixed by your patch. I tried your patch first a few days ago but I my test setup was flawed so I was still testing against the unpatched version of Debian's glibc package. I now managed to test the patched version and this one does indeed work Unpatched: Generating locales (this might take a while)... en_US.UTF-8...localedef: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed. qemu: uncaught target signal 6 (Aborted) - core dumped Aborted done Generation complete. *** update-locale: Error: invalid locale settings: LANG=en_US.UTF-8 (sid-m68k-sbuild)root@nofan:/tmp# Patched: Generating locales (this might take a while)... en_US.UTF-8... done Generation complete. (sid-m68k-sbuild)root@nofan:/tmp# The fix is already in the packaging source of Debian's glibc [1] after I reported the bug. But the updated package has not been uploaded to the FTP servers yet. I'll ask Debian's glibc maintainers to push it. Adrian [1] https://anonscm.debian.org/cgit/pkg-glibc/glibc.git/commit/?id=0a94d5f3ce5785b07372a810f011c62679be910e -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Qemu-devel] /usr/bin/m4: internal error detected
Hi Daniel! On 12/01/2017 06:08 AM, Daniel Kahn Gillmor wrote: Copying file po/Makefile.in.in Copying file po/Makevars.template qemu: Unsupported syscall: -1 m4: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed. /usr/bin/m4: internal error detected; please report this bug to <bug...@gnu.org>: Aborted --- This isn't a bug in m4 or anything architecture-specific, it's a regression that was introduced by an upstream change in glibc [1] and mainly affects qemu-user which we are using for m68k and sh4 [2]. While the change in glibc is most certainly correct (I don't have enough background knowledge to comment on that), it broke qemu-user for everyone and so far there is no possible fix in sight. I am CC'ing this to libc-alpha in the hope that someone from glibc upstream might give us a tip on how to resolve the issue. Not being able to use qemu-user anymore is quite a deal breaker because lots of people use qemu-user for debugging issues on foreign architectures which is now no longer possible. Thanks, Adrian [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=4b4d4056bb154603f36c6f8845757c1012758158 [2] https://bugs.launchpad.net/qemu/+bug/1673976 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Qemu-devel] /usr/bin/m4: internal error detected
On 12/01/2017 01:18 PM, Andreas Schwab wrote: This isn't a bug in m4 or anything architecture-specific, it's a regression that was introduced by an upstream change in glibc [1] and mainly affects qemu-user which we are using for m68k and sh4 [2]. It's a bug in qemu-linux-user, which ignores CLONE_VFORK, turning vfork into fork. This breaks the expected semantics of vfork (VM sharing and blocking the child until exec). Yes, I wasn't really arguing that it's a bug in QEMU as Adhemerval had already explained. The problem was just that apparently resolving the issue in QEMU isn't trivial as Peter Maydell mentioned in [1]. That's why I was looking for a workaround. However, I have re-tested Florian's patch and it works for me now, it didn't when I tested it for the first time. So, we have a workaround for the time being until the bug is resolved in QEMU. Adrian [1] https://bugs.launchpad.net/qemu/+bug/1673976 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Qemu-devel] [Bug 1735384] Re: OpenJDK JVM segfaults on qemu-sh4 (regression)
On 11/30/2017 01:19 PM, Peter Maydell wrote: > This sounds like it may be the bug fixed by this patchset: > https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg05067.html Unfortunately not. I will upload a prepared chroot for testing later and link it in this bug report. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1735384 Title: OpenJDK JVM segfaults on qemu-sh4 (regression) Status in QEMU: New Bug description: Some of the recent changes introduced a regression which makes the OpenJDK JVM crash on qemu-sh4: (sid-sh4-sbuild)root@nofan:/# java -version qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (sid-sh4-sbuild)root@nofan:/# An older version works fine: (sid-sh4-sbuild)root@nofan:/# java -version openjdk version "9.0.1" OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) (sid-sh4-sbuild)root@nofan:/# Haven't had time for bisecting this yet. Adrian To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1735384/+subscriptions
[Qemu-devel] [Bug 1701973] Re: pread does not work right under qemu-sh4
This might be related to this fix: > https://git.qemu.org/?p=qemu.git;a=commit;h=8bf8e9df4a7d82c7a47cc961c9cdee1615595de0 FWIW, if you're interested in sh4, please join #debian-ports on OFTC and subscribe to the debian-superh mailing list. We're doing lots of sh4 development and testing QEMU in Debian. -- 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: 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 not needed, since the program is statically linked here). - ~/inst-qemu/2.9.0/bin/qemu-sh4 test-pread Expected output: ret=1 errno=0 Actual output: ret=0 errno=2 test-pread.c:44: assertion 'ret == 1' failed qemu: uncaught target signal 6 (Aborted) - core dumped To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1701973/+subscriptions
[Qemu-devel] [Bug 1735384] [NEW] OpenJDK JVM segfaults on qemu-sh4 (regression)
Public bug reported: Some of the recent changes introduced a regression which makes the OpenJDK JVM crash on qemu-sh4: (sid-sh4-sbuild)root@nofan:/# java -version qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (sid-sh4-sbuild)root@nofan:/# An older version works fine: (sid-sh4-sbuild)root@nofan:/# java -version openjdk version "9.0.1" OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) (sid-sh4-sbuild)root@nofan:/# Haven't had time for bisecting this yet. Adrian ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1735384 Title: OpenJDK JVM segfaults on qemu-sh4 (regression) Status in QEMU: New Bug description: Some of the recent changes introduced a regression which makes the OpenJDK JVM crash on qemu-sh4: (sid-sh4-sbuild)root@nofan:/# java -version qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (sid-sh4-sbuild)root@nofan:/# An older version works fine: (sid-sh4-sbuild)root@nofan:/# java -version openjdk version "9.0.1" OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) (sid-sh4-sbuild)root@nofan:/# Haven't had time for bisecting this yet. Adrian To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1735384/+subscriptions
[Qemu-devel] [Bug 1701974] Re: pwrite does not work right under qemu-sh4
This might be related to this fix:
>
https://git.qemu.org/?p=qemu.git;a=commit;h=8bf8e9df4a7d82c7a47cc961c9cdee1615595de0
FWIW, if you're interested in sh4, please join #debian-ports on OFTC and
subscribe to the debian-superh mailing list. We're doing lots of sh4
development and testing QEMU in Debian.
--
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 description:
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 using qemu-sh4 (actually not needed, since the
program is statically linked here).
- ~/inst-qemu/2.9.0/bin/qemu-sh4 test-pwrite
Expected output:
buf = 01W3456789
Actual output:
buf = 0123456789
test-pwrite.c:56: assertion 'strcmp ("01W3456789",buf) == 0' failed
qemu: uncaught target signal 6 (Aborted) - core dumped
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1701974/+subscriptions
Re: [Qemu-devel] glibc "linux: spawni.c: simplify error reporting to parent" breaks qemu-user/Windows Service For Linux
On 11/27/2017 05:07 PM, Adhemerval Zanella wrote:> However I am not very compelled to change internal posix_spawn on GLIBC on Linux mainly because it uses a slight less resources than the generic POSIX one (check e83be730910c) and it works on Linux kernel as expected. But it breaks QEMU and Microsoft Windows Services for Linux who - combined together - are certainly not a small number of users. Isn't there any workaround we can use for the time being? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[Qemu-devel] [Bug 1673976] Re: linux-user clone() can't handle glibc posix_spawn() (causes locale-gen to assert)
Interestingly, this also affects Microsoft Windows Services For Linux, i.e. Microsoft's Linux emulation layer. > https://github.com/Microsoft/WSL/issues/1878 ** Bug watch added: github.com/Microsoft/WSL/issues #1878 https://github.com/Microsoft/WSL/issues/1878 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1673976 Title: linux-user clone() can't handle glibc posix_spawn() (causes locale-gen to assert) Status in QEMU: New Bug description: I'm running a command (locale-gen) inside of an armv7h chroot mounted on my x86_64 desktop by putting qemu-arm-static into /usr/bin/ of the chroot file system and I get a core dump. locale-gen Generating locales... en_US.UTF-8...localedef: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0' failed. qemu: uncaught target signal 6 (Aborted) - core dumped /usr/bin/locale-gen: line 41:34 Aborted (core dumped) localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias $locale I've done this same thing successfully for years, but this breakage has appeared some time in the last 3 or so months. Possibly with the update to qemu version 2.8. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1673976/+subscriptions
Re: [Qemu-devel] glibc "linux: spawni.c: simplify error reporting to parent" breaks qemu-user/Windows Service For Linux
On 11/26/2017 09:28 PM, John Paul Adrian Glaubitz wrote: > I'm not sure yet what the actual problem is but I thought it should be > necessary > to point you at the problem. Ok, there is already a QEMU bug report for this [1]. Adrian > [1] https://bugs.launchpad.net/qemu/+bug/1673976 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
