blob: 46ddfd67ced2fb6b97bc4d6903175ad61d815030 (
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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
debug: 0.954
graphic: 0.951
register: 0.902
ppc: 0.847
device: 0.832
performance: 0.828
architecture: 0.803
semantic: 0.784
peripherals: 0.780
network: 0.762
hypervisor: 0.708
vnc: 0.707
risc-v: 0.703
files: 0.690
socket: 0.685
assembly: 0.678
x86: 0.631
permissions: 0.626
PID: 0.616
kernel: 0.605
arm: 0.590
VMM: 0.581
mistranslation: 0.560
TCG: 0.525
user-level: 0.522
KVM: 0.506
i386: 0.499
boot: 0.462
virtual: 0.418
Debugging with Lauterbach Trace32 -> Cortex-A76, no SP register update
Description of problem:
We do not see changes in the SP_EL1 register value when debugging the QEMU application with Lauterbach Trace32.
Steps to reproduce:
1. Compile bare metal code that uses push and pop instructions (stack).
2. Run QEMU with bare metal code.
3. Connect via Lauterbach Trace32 and check the displayed SP register value.
Additional information:
This is a screenshot from QEMU 8.0.0, but updating to QEMU 8.2.0 does not resolve the problem.
I have discussed this with Lauterbach Trace32 support with these results:
- Trace32 uses RSP protocol `p` packets to read some registers, including SP_EL1. GDB seems to use `g` packet.
- QEMU responds to `p` packet with an invalid value, which causes Trace32 to display invalid value.
Some related RSP protocol logs from Trace32.
Different part of RSP protocol log:
```
Sending packet: $p20#d2 ...
receiving packet: ec00004000000000
```
So it looks like Trace32 can receive different values that zero as response to `p` packet.
|