Re: [RFC] Unable to use qemu-ppc to run 32-bit powerpc executables generated on gcc110 machine

2022-08-15 Thread Richard Henderson

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

2022-08-15 Thread Thomas Huth

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

2022-08-12 Thread Pierre Muller



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

2022-08-11 Thread Thomas Huth

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

2022-08-11 Thread Pierre Muller




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,