This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Coredump backtrace frames

Hi ~,

I am trying to get backtrace from a custom coredump handler, on gdb-multi for the c Program running on ARM Cortex R5, on FreeRTOS OS.

Tool chain using is tool chain using is: gcc-arm-none-eabi-9-2019-q4-major-x86_64-linux.
The compiler optimization level is kept at -O2, with -fomit-frame-pointer option during generating the .elf file.

The coredump is catpured when an exception entered, with the register states in the previous processor state( i.e in system mode where the exception has taken).

The Stack Pointer (SP/r13), Link Register (LR/r14) values are copied by switching from exception mode to System mode.
PC(r15) is reduced by offset value #8, when the exception (Data abort) is entered.

When the coredump is loaded for analying where the crash has entered, The backtrace is printing only top 2 frames and remaining frames are not printing.

1. There are only top 2 frames coming in the back trace (from the point where the crash happened).
The other frames are not getting listed by gdb.
Does the coredump capture need to provide any extra information for getting the complete frames?

2. The order of input parameters passed to the function call are reversed when optimization (e.g -O2) is enbled.

Any change need to be added in coredump capture that takes care of giving the correct order of input parameters?

Parents
  • -fomit-frame-pointer omits the storing of stack frame pointers during function calls.

    If you want to have the frame pointers, can you try -fno-omit-frame-pointer compiler option and re-build again?

Reply
  • -fomit-frame-pointer omits the storing of stack frame pointers during function calls.

    If you want to have the frame pointers, can you try -fno-omit-frame-pointer compiler option and re-build again?

Children
No data