Creating dwarf information for ARMv7-A exception handlers

[jh@clesse.com]

Le 2025-11-25 17:47, jh@clesse.com a écrit :
> Hi,
> 
> I am working on an embedded target with a Cortex-A9 CPU. There is a
> debug tool based on Eclipse and gdb 10.2.
> I would like (if it is possible) to have a complete stack trace when
> my code is in the SVC handler.
> I can place a breakpoint at the beginning of my SVC handler, and
> LR_SVC has the right value, but the function call stack is not good
> (later when I change the CPSR mode from SVC to SYS, the call stack
> gets better, but does not go back to the calling USR mode - but that's
> expected, since I change SP and haven't written the needed cfi code
> yet. But going back to the USR call stack is my ideal objective).
> I tried to set the stack base (CFA if I understood properly) to
> R13_SVC (register 164 according to aadwarf32.pdf). I don't know if it
> works, but at least, I get something when I dwarfdump asm_vector.o.
> I also tried to set the return address to R14_SVC (register 165
> according to aadwarf32.pdf), this produces no change to the output of
> dwarfdump. Also the call stack does not change in gdb.
> The code is compile with arm-none-eabi-gcc 11.2.0
> 
> Here is what I tried:
> SVCHandler:									// CPSR mode is SVC
> .type	SVCHandler,%function
> .cfi_sections .debug_frame
> .cfi_startproc
> 
> 	.cfi_def_cfa_register 164						//sp_svc
> 	.cfi_return_column 165							//lr_svc
> 
> 	PUSH	{R0-R3}
> // Do some stuff, changing CPSR mode to SYS
> 	POP	{R0-R3}
> 
> 	SUBS	PC, LR, #0
> 
> .cfi_endproc
> 
> Here is the output of dwarfdump:
> fde:
> <    0><0x0000035c:0x00000428><><cie offset 0x00000000::cie index
> 0><fde offset 0x00000014 length: 0x0000000c><eh offset none>
>         0x0000035c: <off cfa=00(r164) >
> 
> cie:
> <    0>	version				1
> 	cie section offset		0 0x00000000
> 	augmentation
> 	code_alignment_factor		2
> 	data_alignment_factor		-4
> 	return_address_register		165
> 	bytes of initial instructions	7
> 	cie length			16
> 	initial instructions
> 	 0 DW_CFA_def_cfa r13 0
> 	 3 DW_CFA_def_cfa_register r164
> 	 6 DW_CFA_nop
> 
> What am I doing wrong?
> Is there a way to dump the dwarf state in gdb? To try and determine
> what it understands of my code and how it is primed when the
> breakpoint is triggered.
> 
> Best regards,
> JH.

Sorry, my mark I eyeballs, missed that "return_address_register 165" 
line, so the return address setting statement seems to do something. So 
what am I doing wrong? Is the register number wrong? Is it something on 
the gdb side? Is there a user gdb mailing list like 
gcc-help@gcc.gnu.org?