blob: a83d704168bcfa1a94c51f4f16ed501e0ea6dc56 (
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
|
id = 1128
title = "PPC: `spr_write_xer` doesn't set flag bits in `cpu_xer`"
state = "closed"
created_at = "2022-07-29T20:50:24.121Z"
closed_at = "2022-07-29T21:37:44.303Z"
labels = ["Closed::Invalid"]
url = "https://gitlab.com/qemu-project/qemu/-/issues/1128"
host-os = "n/a"
host-arch = "n/a"
qemu-version = "commit: cc42559ab129a15554cc485ea9265e34dde7ab5b"
guest-os = "n/a"
guest-arch = "n/a"
description = """`spr_write_xer()` does not set the `ca`, `ov`, `so`, `ca32`, `ov32` etc. flag bits in the `cpu_xer` variable.
In fact it copies all bits from the source `GPR` and _excludes_ each flag bit.
This is not a problem for execution since `spr_read_xer()` gets the flag bits from `cpu_ca/ov/so...` and not from `cpu_xer`.
Nonetheless it is problem for tools which trace the execution in QEMU (e.g. https://github.com/BinaryAnalysisPlatform/qemu).
A fix would be to remove the `~` in https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L481"""
reproduce = """Haven't found out yet how to debug QEMU so the TCGv values can be investigated. But in general one need to:
- Execute a binary which executes something like:
```
r4 = 0xffffffffffffffff
mtxer r4
```
and check the `cpu_xer` value after the `xer` write.
Checking the debug logs (`in_asm,cpu`) doesn't work, since the `xer` value in the logs is not taken directly from `cpu_xer`."""
additional = """Code ref: https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L480-L483"""
|