AArch64 and fixed return address register (x30)

AArch64 and fixed return address register (x30)

[Sylwester Garncarek]

Hi All,

I've been working on adding CFI directives to assembler sources (GNU 
Asm) of an RTOS and I noticed that GDB seems to ignore 
.cfi_return_column directive. I checked GDB sources and indeed for 
AArch64 architecture the return address is fixed to x30 register. 
Normally this is not a problem, but for exception/interrupt the return 
address is in ELR_mode register. Because GDB is fixed to x30, there is 
no way to get a valid call stack. Are there any plans to make the return 
address register adjustable according to the info provided in DWARF data?

Thanks,
Sylwester

Re: AArch64 and fixed return address register (x30)

[Luis Machado]

Hi,

On 1/3/23 00:50, Sylwester Garncarek via Gdb wrote:
> Hi All,
> 
> I've been working on adding CFI directives to assembler sources (GNU Asm) of an RTOS and I noticed that GDB seems to ignore .cfi_return_column directive. I checked GDB sources and indeed for AArch64 architecture the return address is fixed to x30 register. Normally this is not a problem, but for exception/interrupt the return address is in ELR_mode register. Because GDB is fixed to x30, there is no way to get a valid call stack. Are there any plans to make the return address register adjustable according to the info provided in DWARF data?

It used to be the case that gdb only restored the PC from x30. A recent (ish) patch (1fe8486103e482bcd6cd74fdbf79a7d2ab9b111f) adjusted gdb so the PC can be explicitly set.

You can check how the test does it, and replicate the CFI (gdb.arch/aarch64-unwind-pc.S). From what I recall, gdb was taught about the existence of a formal PC column, which is documented in the aadwarf64 spec [1].

Hopefully that will be useful for your use case.

[1] https://github.com/ARM-software/abi-aa/blob/2022Q1/aadwarf64/aadwarf64.rst#dwarf-register-names

> 
> Thanks,
> Sylwester

Re: AArch64 and fixed return address register (x30)

[Luis Machado]

Hi Sylwester,

On 1/6/23 07:08, Sylwester Garncarek wrote:
> Hi Luis,
> 
> Thank you for pointing me to this commit. I cloned recent sources and I built GDB (before I was using GDB 12.1 sources). The stack looks good now when I can explicitly set the PC.
> 

Great. Thanks for checking and for all the useful info. There might be a genuine bug here indeed. Or rather a limitation of the way things were implemented.

Let me take a look at this first, and I'll get back to you. We might need to open a bug to track this.

Regards,
Luis

> The issue with return address is solved, but now another problem came out. As part of interrupt/exception handling, the RTOS switches stacks. I modified the test source code to show how such task switching works (I'm not restoring the SP later as test_func4 ends up in a dead loop anyway). I'm using x29 register to hold the old stack pointer and I let unwinder know where it can find it:
> 
>          mov x29, sp
>          mov sp, #0x0e000000     //switch stack to 0x0e200000 (also secure RAM in QEMU)
>          add sp, sp, #0x200000
>          .cfi_def_cfa x29, 16
> 
> This is nothing special and I was expecting it to work, however the stack is not complete (please see the screenshot from GDB). I also tested it with Lauterbach's Trace32 ARM Simulator, and stack is being correctly unwinded (also on attached screenshot). To make sure that return address to "test_func()" function is actually taken from the old stack, I destroyed that return address in memory and stack indeed got corrupted, which confirms, that Trace32 correctly understands this stack switching so CFI directives must be correct.
> 
> I attached the modified test source code, linker script for QEMU virt target (CortexA53) and Makefile to build it.
> 
> The launch command for QEMU is:
> 
> qemu-system-aarch64.exe -M virt ^
>      -cpu cortex-a53 ^
>      -m 3G ^
>      -bios gdb-test.bin ^
>      -S ^
>      -gdb tcp:192.168.2.100:3117 ^
>      --machine virtualization=on,secure=true,gic-version=3 ^
>      -smp 1
> 
> Maybe someone knows how GDB deals with cfi_def_cfa directives and could help here.
> 
> 
> BTW: The test source (gdb\testsuite\gdb.arch\aarch64-unwind-pc.S) is not correct, because following three lines:
> 
>          .cfi_def_cfa sp, 16
>          .cfi_offset x29, 0
>          .cfi_offset x30, 8
> 
> should look like this:
> 
>          .cfi_def_cfa sp, 16
>          .cfi_offset x29, -16        <------
>          .cfi_offset x30, -8            <-------
> 
> The offset in .cfi_offset directive should be relative to sp+16, not just sp.
> 
> 
> Thanks,
> Sylwester
> 
> 
>> Hi,
>>
>> On 1/3/23 00:50, Sylwester Garncarek via Gdb wrote:
>>> Hi All,
>>>
>>> I've been working on adding CFI directives to assembler sources (GNU Asm) of an RTOS and I noticed that GDB seems to ignore .cfi_return_column directive. I checked GDB sources and indeed for AArch64 architecture the return address is fixed to x30 register. Normally this is not a problem, but for exception/interrupt the return address is in ELR_mode register. Because GDB is fixed to x30, there is no way to get a valid call stack. Are there any plans to make the return address register adjustable according to the info provided in DWARF data?
>>
>> It used to be the case that gdb only restored the PC from x30. A recent (ish) patch (1fe8486103e482bcd6cd74fdbf79a7d2ab9b111f) adjusted gdb so the PC can be explicitly set.
>>
>> You can check how the test does it, and replicate the CFI (gdb.arch/aarch64-unwind-pc.S). From what I recall, gdb was taught about the existence of a formal PC column, which is documented in the aadwarf64 spec [1].
>>
>> Hopefully that will be useful for your use case.
>>
>> [1] https://github.com/ARM-software/abi-aa/blob/2022Q1/aadwarf64/aadwarf64.rst#dwarf-register-names
>>
>>>
>>> Thanks,
>>> Sylwester
>>
>