Wrong backtrace debugging armcc generated elf

Asked by Menion

Hi all
I'm wondering if anyone can help on this subject.
I have reached a decent success in debugging a monolithic application running on a Cortex R4 with an embedded kernel, using Segger JLink debugger gdbserver and a windows gdb for ARM target, taken from the GNU ARM Embedded project. Everything under the umbrella and the help of GNU ARM Eclipse plugin.
This is the info from the gdb I use:

GNU gdb (GNU Tools for ARM Embedded Processors)
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:
For help, type "help".
Type "apropos word" to search for commands related to "word".

The application is compiled with armcc 5.0.1 (no room for changing it).
The info I can get from file on the elf target:

A2TK_PRJ.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped

As I have said everything works quite ok, I can control the target, break, walk through the code. What it is not working is the backtrace. What I see is that GDB gets a kind of confused, it seems it cannot understand correctly the current frame info and tries to access to some wrong memory location.
Is it anything I can fix with some settings or it is a known limitation when debugging armcc generated elf?

Question information

English Edit question
GNU Arm Embedded Toolchain Edit question
No assignee Edit question
Solved by:
Last query:
Last reply:
Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said :

Hi Menion,

Thanks for the feedback. Could you give us an example of backtrace gone wrong? It would also help us greatly if you could provide a binary for us to reproduce. If you can create a small testcase (say a main function calling a hello_world function) that can reproduce the issue when compiled with armcc and debugged with gdb that would be ideal.

Best regards.

Revision history for this message
Menion (menion) said :

Hi Thomas
What kind of info you need for a valid example of wrong backtrace?
Like registers dump, memory dump or?
Reduce the test case is possible but not fast since I'm quite busy on the work now, but I can try to do the besta I can.
Provide more info on the backtrace is faster, but I need the info above.

Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said :

Hi Menion,

I was thinking about a dump of the backtrace itself (ie the output of a backtrace) and an explanation of why that backtrace is wrong. A dump of the registers (info registers) and the surrounding instruction to where the backtrace starts to go wrong [1] would be very useful as well.

[1] if the backtrace up to function foo (which was calling bar) is fine but go awry when looking for the caller of that function the few instructions before and after the return address in foo (where bar return to). The case I'm thinking is where the backtrace is requested while the program is still in prologue or epilogue for instance.

Best regards.

Revision history for this message
Menion (menion) said :

Hi Thomas
I have built a basic elf that just call some nested function from main. You can download the zip containing source and elf from here: http://www.filehosting.org/file/details/581098/out.zip
Let me know if you succeed to download it
Coming to the backtrace:
Just from the first function jump the backtrace is corrupted, because it say "00" while it should say something like "main at main.c":

#0 func1 (a=10) at mainc.c:19
#1 0x00000000 in ?? ()
#0 func1 (a=10) at mainc.c:19
19 b = func2(a);

info registers
r0 0xa 10
r1 0x0 0
r2 0x0 0
r3 0x1 1
r4 0xa 10
r5 0x60010000 1610678272
r6 0x0 0
r7 0x6000015f 1610613087
r8 0xd8045075 3624161397
r9 0x6804dfb3 1745149875
r10 0x60000170 1610613104
r11 0x60000170 1610613104
r12 0x3958 14680
sp 0x60010024 0x60010024 <__libspace_start+36>
lr 0x600000dc 1610612956
pc 0x600000bc 0x600000bc <func1+8>
cpsr 0x200001d3 536871379

Revision history for this message
Menion (menion) said :

Apparently I have found by myself the problem
The issue is caused by the fact I compile with --dwarf2 option to the armcc
Using nothing or --dwarf3 (that it is the same) makes gdb walking backtrace correctly
But as far as I know, gdb shall support dwarf2 also, or?

Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said :

Hi Menion,

That's good news, I'm glad you found a way to get correct backtrace. To answer your question, yes GDB supports dwarf2 so this means either armcc does not generate correct dwarf2 information, or gdb does not read it correctly. There is of course the possibility that it is a bit of both.

This is indeed something to be fixed but given that this is an example of mixed toolchain (armcc with gdb), this is not of the highest priority. Since you said you cannot change the binary, I would suggest you to use the debugger provided with armcc instead of gdb.

Best regards.

Revision history for this message
Menion (menion) said :

Hi Thomas
Actually this is not possible in an Eclipse environment with embedded target, since that the only why to interact with Segger Jlink is through gdbserver and so gdb is the only option here.
However It's feasable for me to switch to dwarf3. Anyhow the package I have sent to you contains the dwarf2 elf file in case someone what's to give a look at it