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

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

Parents
  • Hello Chen,

    Thank you for your answer and all tips & links.

    1. Indeed, --library_interface=aeabi_clib is AC5 with no known port to AC6. I tried the just in case the option, but it doesn't seem to make sense. It is now removed from the project configuration.

    2. Nothing has changed, the problem is still there. I also tried with IAR 9.50.1, but it's still the same.

    3. I tried using fromelf again and to see where the debugging and symbol reallocation information I'm looking for was located, I can indeed confirm that it is here, in valid sections. I didn't see anything alarming.

    4. Thanks for letting me know about this option! It was worth a try, even if the result was not successful.

Reply
  • Hello Chen,

    Thank you for your answer and all tips & links.

    1. Indeed, --library_interface=aeabi_clib is AC5 with no known port to AC6. I tried the just in case the option, but it doesn't seem to make sense. It is now removed from the project configuration.

    2. Nothing has changed, the problem is still there. I also tried with IAR 9.50.1, but it's still the same.

    3. I tried using fromelf again and to see where the debugging and symbol reallocation information I'm looking for was located, I can indeed confirm that it is here, in valid sections. I didn't see anything alarming.

    4. Thanks for letting me know about this option! It was worth a try, even if the result was not successful.

Children
  • I think you need to contact IAR and provide them with your files so that they can adapt their debugger. Even if compilation tools are DWARF compliant, they have some freedom to generate the debug information. I assume that the IAR debugger is not fully interpret the debug information provided by the Arm compilation toolset. 

  • Hello Hans,

    Indeed, I suppose we did everything we could on Keil's side to make it work. I'll keep this thread open with no accepted answer, so if IAR provides a working one, it could be shared here as well.
    After that, there'll be Keil from GCC to test.

  • Hello everyone, a little message to keep you informed of the progress of this post on the forum.

    It seems to come from the C-Spy debugger. A case was opened on IAR's side to confirm (or not) the issue. IAR versions tested and impacted are 9.20.1 & 9.50.2.

    The last point was to debug an AEABI Keil optimized lib with a GCC project: even with optimizations enabled, the debugging experience here is completely consistent. No issues.

    As stated previously, I will keep this thread open with no accepted answer until one is found.

    Thanks again for all your advice and information provided so far.
    Max