Creating dwarf information for ARMv7-A exception handlers

[jh@clesse.com]

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.