How to debug an AEABI lib built with Keil on another IDE ?

Hello all,

This is my first time posting on a forum, so all feedbacks are welcome in order to improve !

I'll begin with the context information, followed by the issue encountered, and at the end, you'll find all the setup information (e.g. compiler version, and so on).

The context is as follows :

We have several applications that we want to support with different compilers : Clang (Keil), GCC, and IAR.

We also have two libraries that we offer in black box form and with an API defined in our headers so that people using our applications only focus on the application itself and not what's behind the scenes. To achieve this, we built the libraries with Keil and following the AEABI recommendations (Misc Controls added in the Linker panel : --library_interface=aeabi_clib).

Functionally speaking, it is working fine on the 3 compilers when we use the Keil libs into our applications.

The issue I'm facing is how to debug such libs.

When the application is a Keil project, so the app is Keil, and libs are Keil, the debugging experience is excellent, even with optimizations enabled. The call stack is 100% consistent, no address jumps or offsets are introduced, all function calls are perfectly followed.

However, when the application is let's say an IAR one, so the app is built with IAR, and the libs are still made with Keil, it sometimes happens that an offset is introduced, leading to some function calls not being tracable, like let's say this case :

• Function A calls Function B, which calls Function C, which also calls Function D. The callstack is therefore expected to be as such :
  • Function D // <-- let's say we stopped here to check the content of some variables / pointers
  • Function C
  • Function B
  • Function A
• However, what I see is that :
  • Function D // <-- let's say we stopped here to check the content of some variables / pointers
  • [ Function C + 0x31 ] // <-- issue here : the name of the expected function but with an offset : can't click or investigate into Function C
  • Function B
  • Function A

At first, I thought it was coming from optimizations, but after removing them during investigations and regarding how the debugging experience for a 100% Keil case was with them enabled, I arrived at the conclusion that it might come from a debug information mismatch between Keil generated debug information and how the IAR debugger interprets them.

• By default, as stated by the arm_compiler_user_guide_100748_6.21_00_en.pdf, chapter 3.5 page 55 : "The -g option is a synonym for -gdwarf-4."
• On IAR's side, it is also using gdwarf-4 format.

However, I also found on this github : https://github.com/ARM-software/abi-aa/blob/main/aadwarf32/aadwarf32.rst#overview that "The ABI for the Arm architecture specifies the use of DWARF 3.0-format debugging data". According to the standard itself, https://dwarfstd.org/dwarf4std.html, gdwarf 3.0 and 4.0 are compatible.

Anyway, I've also tried setting gdwarf 3.0 as the debug format for Keil libs by adding this into the Compiler Misc Control panel (and by removing the use of 'Debug Information" in the Output panel) : -g -g3 -gdwarf-3 -gstrict-dwarf

But it didn't work either way.

Does anyone know what's going on behind the scenes and how to fix this if it happens to any of you please ? I'm running out of ideas for debugging Keil libraries on IAR.

If the debug information mismatch isn't the subject to investigate, what advice and investigations tips can you give me please ?

Setup information :

• Keil setup :
  • uVision v5.38.0.0
  • Toolchain : ARMCLANG AC6, v6.19
  • Misc Controls added in the Linker panel : --library_interface=aeabi_clib
• IAR setup :
  • IAR Embeeded Workbench for ARM - v9.20.1

Thank you for your help to understand what's happening ! I wish you a great day,

Max