Creating and using dwarf information for ARMv7-A exception handlers

Creating and using dwarf information for ARMv7-A exception handlers

[jh--- via Gdb]

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 the "return_address_register 
165" (instead of 14 which is LR as expected) output of dwarfdump. But 
the call stack does not change in gdb (or more precisely in Eclipse).
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
// Change CPSR mode back to SVC
	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.
Is the register number wrong? Is it something on the gdb side?

Best regards,
JH.

Re: Creating and using dwarf information for ARMv7-A exception handlers

[Basile Starynkevitch]

On Wed, 2025-11-26 at 11:00 +0100, jh--- via Gdb wrote:
> 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.


Did you consider using (in your code, not in GDB) https://github.com/ianlancetaylor/libbacktrace
-- 

Basile STARYNKEVITCH                    basile AT starynkevitch DOT net
8 rue de la Faïencerie                       http://starynkevitch.net/Basile/  
92340 Bourg-la-Reine                         https://github.com/bstarynk
France                                https://github.com/RefPerSys/RefPerSys
                  https://orcid.org/0000-0003-0908-5250

Re: Creating and using dwarf information for ARMv7-A exception handlers

[jh--- via Gdb]

Le 2025-11-26 11:05, Basile Starynkevitch a écrit :
> On Wed, 2025-11-26 at 11:00 +0100, jh--- via Gdb wrote:
>> 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.
> 
> 
> Did you consider using (in your code, not in GDB)
> https://github.com/ianlancetaylor/libbacktrace

Hi,

Thank you for you answer.
Is gdb using libbacktrace to perform the call stack unwind?

Best regards,
JH.

Re: Creating and using dwarf information for ARMv7-A exception handlers

[Basile Starynkevitch]

On Thu, 2025-11-27 at 09:13 +0100, jh@clesse.com wrote:
> Le 2025-11-26 11:05, Basile Starynkevitch a écrit :
> > On Wed, 2025-11-26 at 11:00 +0100, jh--- via Gdb wrote:
> > > 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.
> > 
> > 
> > Did you consider using (in your code, not in GDB)
> > https://github.com/ianlancetaylor/libbacktrace
> 
> Hi,
> 
> Thank you for you answer.
> Is gdb using libbacktrace to perform the call stack unwind?


Perhaps it does, but it is irrelevant since the address space of your debugger process is not the
the address space of your software application. I am assuming you do use some operating system.

For your information, the GCC compiler is using libbacktrace, to show its call trace on fatal compilation errors
(in theory they don't happen).

If you compile your code using GCC (it is probably invoked by Eclipse) you do use libbacktrace indirectly.

If you are developing some code running on a bare metal CPU, you still could (with additional efforts) 
link libbacktrace inside it to show the call stack.

My RefPerSys project is using it (on Linux).

Regards.

NB: We probably are both French, so you could email me privately in French. See https://arxiv.org/abs/1109.0779
and https://frama-c.com/

-- 

Basile STARYNKEVITCH                    basile AT starynkevitch DOT net
8 rue de la Faïencerie                       http://starynkevitch.net/Basile/  
92340 Bourg-la-Reine                         https://github.com/bstarynk
France                                https://github.com/RefPerSys/RefPerSys
                  https://orcid.org/0000-0003-0908-5250

Re: Creating and using dwarf information for ARMv7-A exception handlers

[Tom Tromey]

>>>>> jh--- via Gdb <gdb@sourceware.org> writes:

> I would like (if it is possible) to have a complete stack trace when
> my code is in the SVC handler.

I don't know anything about ARM.  However it's often the case that
unwinding through special frames requires some extra support, either
some flag in the debuginfo somewhere, or a special unwinder in gdb.

> 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.
> Is the register number wrong? Is it something on the gdb side?

There's no simple answer to these questions.  Unwinding in gdb is rather
complicated.

You can sometimes get some info with "set debug frame 1".
However the normal method is to debug gdb and try to understand what's
gone wrong.

I do see a lot of unwinding code in arm-tdep.c.  I'd expect a lot of
that to be bypassed, though, if the DWARF describes the frame in question.
If so then you'd be looked at debugging through the DWARF unwinder.

Tom