summary refs log tree commit diff stats
path: root/gitlab/issues_text/target_arm/host_missing/accel_TCG/876
blob: 8d819538ee8b2f75981e68bd98167878765a7e43 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
snek-arm fails on s390x with qemu >6.1
Description of problem:
snek is a language inspired by python for embedded. The tests run snek code natively (in this case on s390x) as well as in python3 as well as emulated for arm.
The latter is what fails...

the Ubuntu testing has spotted this in:

- https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/s390x/s/snek/20220211_065108_2144a@/log.gz
- https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/s390x/s/snek/20220212_050524_3b7ee@/log.gz
- https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/s390x/s/snek/20220214_080226_46968@/log.gz

In there all work, but one test fails reproducible, that is `test/pass-slice.py`

When eliminating the automation in makefiles and all that it comes down to:
```
$ qemu-system-arm -chardev stdio,mux=on,id=stdio0 -serial none -monitor none -semihosting-config enable=on,chardev=stdio0,arg='snek',arg=test/pass-slice.py -machine mps2-an385,accel=tcg -cpu cortex-m3 -kernel /usr/share/snek/snek-qemu-arm-1.7.elf -nographic -bios none
fail: [::-5] (model 'o' impl '')
```

To be clear:
- the test for python3 works on all platforms
- the test for snek-native works on all platforms
- the test for snek-arm work on all platforms except s390x
- with qemu 6.0 this worked, but the more recent qemu 6.2 makes it fail
- only some subtests of pass-slice.py fail (see below)

I've gone into some details for the snek side of things in [the bug report there](https://github.com/keith-packard/snek/issues/58).
Steps to reproduce:
1. get an s390x system
2. get the snek elf file for arm
3. run qemu-system-arm as shown above

P.S. I tried this on latest head (building qemu in an F35 container) and it fails there as well, hence I'm listing commit 2d88a3a595 as affected as well.
We know 6.0 was ok, so likely 6.0->6.1 brought the issue, I have not yet checked if a bisect is feasible for this.