Re: [RFC] Unable to use qemu-ppc to run 32-bit powerpc executables generated on gcc110 machine
On 8/15/22 02:47, Thomas Huth wrote: Ok, I see, so the question is wether it is somehow possible to enable the vector extensions on a 32-bit CPU by default somehow... CC:-ing Laurent, maybe he knows... You'd do this for ppc32-user-only by defining e.g. a power9 cpu, and setting all the bits so that it's in narrow mode, and the correct endianness. r~
Re: [RFC] Unable to use qemu-ppc to run 32-bit powerpc executables generated on gcc110 machine
On 12/08/2022 09.03, Pierre Muller wrote: Le 12/08/2022 à 06:16, Thomas Huth a écrit : On 11/08/2022 23.38, Pierre Muller wrote: I am using qemu to check code generated by Free Pascal compiler for various CPUs. Recently, this allowed me to find out that Free Pascal was generating wrong instructions, leading to SIGBUS errors using qemu-mips. The same binaries worked without troubles on mips test machines, probably because SIGBUS is handled directly inside the kernel. Here I would like to report the problem I get when trying to run powerpc executables using shared libs generated on gcc110 machine. I copied over the needed libraries into a sys-root directory. The problem is that the code crashes with a Illegal Instruction after only a very few instructions: muller@gcc186:~/pas/check$ ~/sys-root/bin/qemu-ppc -cpu g2 -d in_asm -L ~/sys-root/powerpc-linux ./twide1 [...] 0x3ffc1d60: f4d7 xxlxor v0, v0, v0 qemu: uncaught target signal 4 (Illegal instruction) - core dumped The problem is the the 'xxlxor' instruction is a VSX extension instruction. There is apparently no cpu in the powerpc cpu list that enabled this extension. The output of cat /proc/cpuinfo on gcc110 gives that: . processor : 63 cpu : POWER7 (architected), altivec supported clock : 3550.00MHz revision : 2.1 (pvr 003f 0201) timebase : 51200 platform : pSeries model : IBM,8231-E2B machine : CHRP IBM,8231-E2B Is there a way to enable cpu features separately for ppc like is done for x86_64? Or would it be possible to define a new cpu inside qemu source that would match the description above? So you are building on a POWER7 host and try to run the binaries on an emulated G2? That sounds weird. Why don't you use The g2 was just an example, I used a script to iterate over all possible cpus (as listed by --cpu help), but I always get a Illegal instruction on xllxor, because none of the cpu in the least seems to enable VSX extension. Ok, I see, so the question is wether it is somehow possible to enable the vector extensions on a 32-bit CPU by default somehow... CC:-ing Laurent, maybe he knows... Thomas
Re: [RFC] Unable to use qemu-ppc to run 32-bit powerpc executables generated on gcc110 machine
Le 12/08/2022 à 06:16, Thomas Huth a écrit : On 11/08/2022 23.38, Pierre Muller wrote: I am using qemu to check code generated by Free Pascal compiler for various CPUs. Recently, this allowed me to find out that Free Pascal was generating wrong instructions, leading to SIGBUS errors using qemu-mips. The same binaries worked without troubles on mips test machines, probably because SIGBUS is handled directly inside the kernel. Here I would like to report the problem I get when trying to run powerpc executables using shared libs generated on gcc110 machine. I copied over the needed libraries into a sys-root directory. The problem is that the code crashes with a Illegal Instruction after only a very few instructions: muller@gcc186:~/pas/check$ ~/sys-root/bin/qemu-ppc -cpu g2 -d in_asm -L ~/sys-root/powerpc-linux ./twide1 [...] 0x3ffc1d60: f4d7 xxlxor v0, v0, v0 qemu: uncaught target signal 4 (Illegal instruction) - core dumped The problem is the the 'xxlxor' instruction is a VSX extension instruction. There is apparently no cpu in the powerpc cpu list that enabled this extension. The output of cat /proc/cpuinfo on gcc110 gives that: . processor : 63 cpu : POWER7 (architected), altivec supported clock : 3550.00MHz revision : 2.1 (pvr 003f 0201) timebase : 51200 platform : pSeries model : IBM,8231-E2B machine : CHRP IBM,8231-E2B Is there a way to enable cpu features separately for ppc like is done for x86_64? Or would it be possible to define a new cpu inside qemu source that would match the description above? So you are building on a POWER7 host and try to run the binaries on an emulated G2? That sounds weird. Why don't you use The g2 was just an example, I used a script to iterate over all possible cpus (as listed by --cpu help), but I always get a Illegal instruction on xllxor, because none of the cpu in the least seems to enable VSX extension. qemu-ppc64 -cpu power7 ... Because I am interested in testing 32-bit ELF binaries: muller@gcc186:~/pas/check$ file ./twide1 ./twide1: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, stripped muller@gcc186:~/pas/check$ qemu-ppc64 -cpu power7 ./twide1 -bash: qemu-ppc64: command not found muller@gcc186:~/pas/check$ ~/sys-root/bin/qemu-ppc64 -cpu power7 ./twide1 qemu-ppc64: ./twide1: Invalid ELF image for this architecture muller@gcc186:~/pas/check$ ~/sys-root/bin/qemu-ppc64 --version qemu-ppc64 version 7.0.0 Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers muller@gcc186:~/pas/check$ ~/gnu/qemu/build-qemu-7.1.0-rc2/qemu-ppc64 -cpu power7 ./twide1 qemu-ppc64: ./twide1: Invalid ELF image for this architecture So qemu-ppc64 (7.0.0 and 7.1.0-rc2) is only able to run 64-bit binaries. Pierre
Re: [RFC] Unable to use qemu-ppc to run 32-bit powerpc executables generated on gcc110 machine
On 11/08/2022 23.38, Pierre Muller wrote: I am using qemu to check code generated by Free Pascal compiler for various CPUs. Recently, this allowed me to find out that Free Pascal was generating wrong instructions, leading to SIGBUS errors using qemu-mips. The same binaries worked without troubles on mips test machines, probably because SIGBUS is handled directly inside the kernel. Here I would like to report the problem I get when trying to run powerpc executables using shared libs generated on gcc110 machine. I copied over the needed libraries into a sys-root directory. The problem is that the code crashes with a Illegal Instruction after only a very few instructions: muller@gcc186:~/pas/check$ ~/sys-root/bin/qemu-ppc -cpu g2 -d in_asm -L ~/sys-root/powerpc-linux ./twide1 [...] 0x3ffc1d60: f4d7 xxlxor v0, v0, v0 qemu: uncaught target signal 4 (Illegal instruction) - core dumped The problem is the the 'xxlxor' instruction is a VSX extension instruction. There is apparently no cpu in the powerpc cpu list that enabled this extension. The output of cat /proc/cpuinfo on gcc110 gives that: . processor : 63 cpu : POWER7 (architected), altivec supported clock : 3550.00MHz revision : 2.1 (pvr 003f 0201) timebase : 51200 platform : pSeries model : IBM,8231-E2B machine : CHRP IBM,8231-E2B Is there a way to enable cpu features separately for ppc like is done for x86_64? Or would it be possible to define a new cpu inside qemu source that would match the description above? So you are building on a POWER7 host and try to run the binaries on an emulated G2? That sounds weird. Why don't you use qemu-ppc64 -cpu power7 ... ? Thomas
Re: [RFC] Unable to use qemu-ppc to run 32-bit powerpc executables generated on gcc110 machine
Le 11/08/2022 à 23:38, Pierre Muller a écrit : I am using qemu to check code generated by Free Pascal compiler for various CPUs. Recently, this allowed me to find out that Free Pascal was generating wrong instructions, leading to SIGBUS errors using qemu-mips. The same binaries worked without troubles on mips test machines, probably because SIGBUS is handled directly inside the kernel. Here I would like to report the problem I get when trying to run powerpc executables using shared libs generated on gcc110 machine. I copied over the needed libraries into a sys-root directory. The problem is that the code crashes with a Illegal Instruction after only a very few instructions: muller@gcc186:~/pas/check$ ~/sys-root/bin/qemu-ppc -cpu g2 -d in_asm -L ~/sys-root/powerpc-linux ./twide1 IN: _start 0x3ffda784: 7c230b78 mr r3, r1 0x3ffda788: 3880 li r4, 0 0x3ffda78c: 3821fff0 addi r1, r1, -0x10 0x3ffda790: 9081 stw r4, 0(r1) 0x3ffda794: 4bfe756d bl 0x3ffc1d00 IN: _dl_start 0x3ffc1d00: 9421fd40 stwu r1, -0x2c0(r1) 0x3ffc1d04: 7c0802a6 mflr r0 0x3ffc1d08: 429f0005 bdnzl0x3ffc1d0c IN: _dl_start 0x3ffc1d0c: 93c102b8 stw r30, 0x2b8(r1) 0x3ffc1d10: 938102b0 stw r28, 0x2b0(r1) 0x3ffc1d14: 92e1029c stw r23, 0x29c(r1) 0x3ffc1d18: 930102a0 stw r24, 0x2a0(r1) 0x3ffc1d1c: 7fc802a6 mflr r30 0x3ffc1d20: 932102a4 stw r25, 0x2a4(r1) 0x3ffc1d24: 934102a8 stw r26, 0x2a8(r1) 0x3ffc1d28: 936102ac stw r27, 0x2ac(r1) 0x3ffc1d2c: 900102c4 stw r0, 0x2c4(r1) 0x3ffc1d30: 93a102b4 stw r29, 0x2b4(r1) 0x3ffc1d34: 93e102bc stw r31, 0x2bc(r1) 0x3ffc1d38: 7c7c1b78 mr r28, r3 0x3ffc1d3c: 3fde0004 addisr30, r30, 4 0x3ffc1d40: 3bded2d0 addi r30, r30, -0x2d30 0x3ffc1d44: 7d4d42a6 mfsprr10, 0x10d 0x3ffc1d48: 7d2c42a6 mfsprr9, 0x10c 0x3ffc1d4c: 7d0d42a6 mfsprr8, 0x10d 0x3ffc1d50: 7c0a4000 cmpw r10, r8 0x3ffc1d54: 4082fff0 bne 0x3ffc1d44 IN: _dl_start 0x3ffc1d58: 91410268 stw r10, 0x268(r1) 0x3ffc1d5c: 38e00013 li r7, 0x13 0x3ffc1d60: f4d7 xxlxor v0, v0, v0 Small improvement, with 7.1.0-rc2, with capstone library, I get: muller@gcc186:~/pas/check$ ~/gnu/qemu/build-qemu-7.1.0-rc2/qemu-ppc -cpu g2 -L ~/sys-root/powerpc-linux -d in_asm ./twide1 IN: _dl_start 0x3ffc1d58: 91410268 stw r10, 0x268(r1) 0x3ffc1d5c: 38e00013 li r7, 0x13 0x3ffc1d60: f4d7 xxlxor vs32, vs32, vs32 qemu: uncaught target signal 4 (Illegal instruction) - core dumped Illegal instruction The only difference I get, when scanning the whole cpu list, is that a few of them abort even before starting to display powerpc instructions: muller@gcc186:~/pas/check$ ~/gnu/qemu/build-qemu-7.1.0-rc2/qemu-ppc -cpu 755 ./twide1 qemu-ppc: ../qemu-7.1.0-rc2/target/ppc/helper_regs.c:330: _spr_register: Assertion `spr->name == NULL' failed. Aborted The special register HID0 seems to be set twice: First time: Thread 1 "qemu-ppc" hit Breakpoint 1, _spr_register (env=env@entry=0x558619d0, num=num@entry=1008, name=name@entry=0x55714fe2 "HID0", uea_read=uea_read@entry=0x555d3e40 , uea_write=uea_write@entry=0x555d3e40 , initial_value=initial_value@entry=0) at ../qemu-7.1.0-rc2/target/ppc/helper_regs.c:330 330 assert(spr->name == NULL); $38 = 0x55714fe2 "HID0" (gdb) bt #0 _spr_register (env=env@entry=0x558619d0, num=num@entry=1008, name=name@entry=0x55714fe2 "HID0", uea_read=uea_read@entry=0x555d3e40 , uea_write=uea_write@entry=0x555d3e40 , initial_value=initial_value@entry=0) at ../qemu-7.1.0-rc2/target/ppc/helper_regs.c:330 #1 0x555ab69a in register_7xx_sprs (env=env@entry=0x558619d0) at ../qemu-7.1.0-rc2/target/ppc/cpu_init.c:210 #2 0x555ad12f in init_proc_745 (env=env@entry=0x558619d0) at ../qemu-7.1.0-rc2/target/ppc/cpu_init.c:4010 #3 0x555ad25f in init_proc_755 (env=0x558619d0) at ../qemu-7.1.0-rc2/target/ppc/cpu_init.c:4067 #4 0x555ae9e3 in init_ppc_proc (cpu=0x558596a0) at ../qemu-7.1.0-rc2/target/ppc/cpu_init.c:6697 #5 ppc_cpu_realize (dev=0x558596a0, errp=0x7fffd0c0) at ../qemu-7.1.0-rc2/target/ppc/cpu_init.c:6846 #6 0x556b7a1e in device_set_realized (obj=, value=, errp=0x7fffd1f0) at ../qemu-7.1.0-rc2/hw/core/qdev.c:553 #7 0x556bbb56 in property_set_bool (obj=0x558596a0, v=, name=, opaque=0x5584ab60, errp=0x7fffd1f0) at ../qemu-7.1.0-rc2/qom/object.c:2273 #8 0x556beb84 in object_property_set (obj=obj@entry=0x558596a0, name=name@entry=0x5572fb1f "realized", v=v@entry=0x558525a0, errp=errp@entry=0x7fffd1f0) at ../qemu-7.1.0-rc2/qom/object.c:1408 #9 0x556c1f20 in object_property_set_qobject (obj=obj@entry=0x558596a0,