Wrong backtrace debugging armcc generated elf

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.

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.
Bye

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.

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":

bt
#0 func1 (a=10) at mainc.c:19
#1 0x00000000 in ?? ()
frame
#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

Hi
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?

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.

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
Bye