[lldb] Incorrect RISC-V register values displayed

[patryk4815]

LLDB for some reason display wrong register.

This issue occurs when running the same program on an ESP32-C3 (a simple blinking LED application).
Specifically, the sp register, along with other registers, shows a value different from what is reported in the g packet.

LLDB (invalid):

GDB (good):

Additional note: After switching to thread 2, the register values are displayed correctly.

Environment:

• target esp32-c3 (riscv32)
• Open On-Chip Debugger v0.12.0-esp32-20241016 (2024-10-16-14:17)
• lldb version 19.1.1

[llvmbot]

@llvm/issue-subscribers-lldb

Author: None (patryk4815)

LLDB for some reason display wrong register.

This issue occurs when running the same program on an ESP32-C3 (a simple blinking LED application).
Specifically, the sp register, along with other registers, shows a value different from what is reported in the g packet.

LLDB (invalid):
<img width="1068" alt="Image" src="https://github.com/user-attachments/assets/1b9bdba6-6d74-4d75-95ea-beae1504ab59" />

GDB (good):
<img width="1173" alt="Image" src="https://github.com/user-attachments/assets/020f25f7-b994-4e2f-bea8-7510a66e7d10" />

Additional note: After switching to thread 2, the register values are displayed correctly.

Environment:

• target esp32-c3 (riscv32)
• Open On-Chip Debugger v0.12.0-esp32-20241016 (2024-10-16-14:17)
• lldb version 19.1.1

[DavidSpickett]

Ideally registers are described in an XML document sent to LLDB when we first connect. We get the layout of the register data from this.

If we don't get that information, some targets have a fallback layout. Which is essentially what GDB would assume the layout is. I don't know whether we have done that for RISC-V, but if we are not getting XML, some assumptions must be being made here and it would be weird for one thread to assume a different layout to another.

(unless that thread had more registers enabled?)

You can see if XML is sent by enabling logging before you connect to the debug target:

(lldb) log enable gdb-remote packets

Then you're looking for something like:

lldb             <  43> send packet: $qXfer:features:read:target.xml:0,131071#78
lldb             <24902> read packet: $l<?xml version="1.0"?>
<target version="1.0">
  <architecture>x86_64</architecture>
  <feature>
    <reg name="rax" bitsize="64" regnum="0" offset="80" encoding="uint" format="hex" group="General Purpose Registers" ehframe_regnum="0" dwarf_regnum="0" />
    <reg name="rbx" bitsize="64" regnum="1" offset="40" encoding="uint" format="hex" group="General Purpose Registers" ehframe_regnum="3" dwarf_regnum="3" />
    <reg name="rcx" bitsize="64" regnum="2" offset="88" encoding="uint" format="hex" group="General Purpose Registers" ehframe_regnum="2" dwarf_regnum="2" generic="arg4" />

I would also not rely on the order of register display to be the order of the data in the G packet. It's possible it is, but I doubt that's always the case.

There are stack frames, but only one so we could have got that from the return address only. Which means we don't have the right sp, but fail to display it correctly.

Edit: I was looking at the thread list thinking it was the backtrace.

If thread #2 works, could you also look at the G packet contents for thread 2? I wonder if the location of the sp value changes.

I assume the threads here are not hardware threads but FreeRTOS threads, so I'm tempted to point to OpenOCD's FreeRTOS awareness as the problem, but if GDB manages, LLDB should too.

[DavidSpickett]

https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterFallback.cpp has the fallback layouts, I don't see RISC-V here. My guess is that we just hope that LLDB's layout matches the debug target's in this case.

[patryk4815]

@DavidSpickett
Full dump with packets:
gdb-log.txt
lldb-log.txt

I see lldb don't send g packet at all 🤔

[patryk4815]

It seems that the p packets are returning incorrect data from Open On-Chip Debugger. This appears to be an issue with OpenOCD?

[DavidSpickett]

Somewhere I remember there is a reason for us not using the g packet, probably because GDB's assumptions about its layout are not the same as ours, but in any case, repeated p should work.

I see lldb reading what I think is sp for thread 1 twice:

.lldb-wrapped    <   6> send packet: $p2#a2
.lldb-wrapped    <  12> read packet: $70fdc83f#65

The first one matches what GBD showed:

sp             0x3fc8fd70       0x3fc8fd70

But then the value changes:

.lldb-wrapped    <   6> send packet: $p2#a2
.lldb-wrapped    <  12> read packet: $0a000000#b1

Not sure why lldb needs to re-read it there, but it should be the same value anyway.

You could try manually sending p with GDB and see if that has the same result. If so, then I think yes this is something wrong in OpenOCD.

(this isn't uncommon, debug servers like OpenOCD are generally tested against GDB only, so it's easy to miss things)

[patryk4815]

Reported in espressif/openocd-esp32#352