Fix incorrect register values returned in p packet for ESP32-C* (RISC-V) on FreeRTOS (OCD-1055)

[patryk4815]

Description

This change addresses a bug where the p packets were returning incorrect values.
Initially, I reported this issue to lldb on GitHub (see: llvm/llvm-project#121712 ), thinking the problem was on the lldb side.
However, it turned out that the issue was in OpenOCD.

Example buggy behavior:

pwndbg> thread 1
pwndbg> maintenance packet g
sending: g
received: "000000006ab60042[^1]80fdc83f[^1]00c2c83f10fec83f00000000000000000000000000e0c83f01000000000000009ffdc83f0100000024fec83f0100000000f00160000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006ab60042"
pwndbg> p $sp
$2 = (void *) 0x3fc8fd80
pwndbg> maintenance packet p2
sending: p2
received: "80fdc83f"

pwndbg> thread 2
pwndbg> p $sp
$1 = (void *) 0x3fc8f610
pwndbg> maintenance packet g
sending: g
received: "00000000124b3840[^2]10f6c83f[^2]00c2c83fc0f6c83f0e89054000000030000000003200000000000000010000000100000000000000040000000100000000000c60003002600a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000074273840"
pwndbg> maintenance packet p2
sending: p2
received: "0a000000"

The maintenance packet p2 should return a value corresponding to the sp register, but it did not behave as expected.
I am not very familiar with FreeRTOS, but this fix solves the problem with incorrect p packet behavior.

Type of change

• Bug fix (non-breaking change which fixes an issue)

Hardware Configuration:

• Module or Chip Used: esp32-c3 (freertos)

[erhankur]

@patryk4815 Thanks for the PR. The register order matters and should be aligned with the ESP-IDF register saving during exceptions/task_yield. We have two different stackings for Xtensa but only one for RISC-V. We will check this part in the IDF. If there is something to fix, internal MR will be created first and then it will be synced here.

[erhankur]

Even with the incorrect order in OpenOCD, the g packet was working because OpenOCD constructs the response without mapping with the GDB reg nums.

However, for the p packet, OpenOCD retrieves registers from the stack by mapping GDB register numbers to stacking_offsets . For example, the SP register is at an offset of 0x8 in the stack, but in OpenOCD's stacking_offsets, it is expected to be at 0x44. Therefore, OpenOCD copies the register value from offset 0x44 instead of 0x8.

@patryk4815 This is fixed in the master branch now. 242ac4a

[patryk4815]

@erhankur thank you! Now I will check lldb :)