8

I have some baremetal AARCH64 software running in QEMU. I connect GDB to it as a remote target. GDB multi-arch shows general purpose registers from x0 to x30, the SP, and PC.

However, I can't find a way to access the system registers to inspect things like the DAIF system register, the Fault Address Register, Fault Syndrome Register, etc. These are essential for debugging. I've tried within QEMU using info all-registers but the output doesn't seem relevant.

Am I missing something obvious?

PS, the QEMU model is the following:

qemu-system-aarch64 -machine virt,gic_version=3 -cpu cortex-a57 -smp 4 -m 4096

Ciro Santilli OurBigBook.com
  • 347,512
  • 102
  • 1,199
  • 985
Jon Bovi
  • 91
  • 1
  • 4

3 Answers3

9

No, you dont missing anything: it is impossible to view aarch64 system registers with the stock qemu as a gdb remote target.

But you could add a small changes to qemu to view them.

Gdb client connects to QEMU over GDB RSP protocol. Server part of this protocol implemented at QEMU is called "gdb stub" (also it is common term for many other simulators/embedded software).

At the very beginning of client and stub communications, stub sends to client a target desription - a xml file with all registers that client allowed to request. Here is a such file for qemu aarch64 target. As you can see, info all-registers command at client prints all this registers, not more.

If you simple add required registers to that file it doesn`t work, you also need to add a few lines to aarch64_cpu_gdb_read_register - that functions reads registers from qemu internals and pass them to gdbstub.

After that build qemu, and you got it.

Also that question will help you to view a client/stub communication details, if something goes wrong.

Jettatura
  • 534
  • 2
  • 10
  • Maybe it would be simpler to expose the registers on qemu monitor `info registers` (not exposed as of v3.0.0), which then can also be accessed through GDB with `monitor info registers`. It is also worth noting that EL2 is a recent addition as of 2018, and EL3 is not implemented, so maybe not all registers will be meaningful? https://stackoverflow.com/questions/42824706/qemu-system-aarch64-entering-el1-when-emulating-a53-power-up – Ciro Santilli OurBigBook.com Aug 11 '18 at 20:40
4

QEMU 3.x+ exposes the aarch64 system registers in the normal info registers command. For example:

(gdb) info registers 
...
MVFR1_EL1      0x12111111   303108369
MDRAR_EL1      0x0  0
OSLSR_EL1      0xa  10
CTR_EL0        0x8444c004   2219098116
REVIDR_EL1     0x0  0
SCTLR          0xc50838 12912696
ACTLR_EL1      0x0  0
CPACR          0x0  0
...

It was implemented in https://github.com/qemu/qemu/commit/200bf5b7ffe.

1

QEMU tells GDB which registers it knows about by sending XML files in GDB's Target Description format: https://sourceware.org/gdb/onlinedocs/gdb/Target-Descriptions.html#Target-Descriptions

Some of those, are simply tracked in-tree as XML files directly: https://github.com/qemu/qemu/tree/v3.0.0/gdb-xml and may be from the GDB tree: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/features/aarch64-core.xml;h=eb6364eb0996313420a4098509cb7f0e0fc32bec

But others are generated on the fly to reflect system configuration.

In particular, system registers are generated on the fly and sent as system-registers.xml, see: https://github.com/qemu/qemu/blob/v3.0.0/target/arm/gdbstub.c#L174

So, whatever registers you are missing, you should add them to that XML, and populate them with the correct values like the others.

And then send a patch to upstream QEMU :-)

Ciro Santilli OurBigBook.com
  • 347,512
  • 102
  • 1,199
  • 985