• State
  • Locked Locked
  • Replies 12 replies
  • Subscribers 30 subscribers
  • Views 383 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RM48L952: Assembly Language Dwarf-3 debug information from Arm FuSa compiled static library for RTOS threadx is not being displayed by CCS Debugger

Kip Leitner
Prodigy 196 points
Part Number: RM48L952

Tool/software:

I am using CCS version 12.8.1 to compile, assemble, link and debug code for TI Hercules processor RM48L952.  The processor is running on TI's development kit for Hercules Microcontrollers.  

I have been using development environment for almost a year now and it is stable and works well in all other aspects.

The final link adds threadx, which is built as a static library using ARM FuSa tool chain and ARM FuSa compiler Arm® Compiler for Embedded FuSa Version 6.16.2 LTS.

All aspects code execution in the TI CCS debugger are working properly.  This is ONLY a matter of the CCS Debugger NOT DISPLAYING, while debugging ARM ASM source code in the debugger.  The ARM C/C++ source code for threadx is displaying properly in the CCS Debugger. 

++++++++++++++++++++++++++++

Example:

Single stepping C/C++ code from the ARM static library in CCS Debugger works OK.  Execution is at entry into an ASM function in threadx static library:  "threadx_XDER_611.a", executing single step ASM code into function _tx_thread_schedule():

So, after single ASM stepping, the disassembly window is is correct, but in the blank window above, we see the message from the CCS Debugger:

No source available for "_tx_thread_schedule() at C:\Users\Kip_Leitner\workspace_v12_8_1\IslandDER\Debug\IslandDER.out:{3} 0xd6e0{4}"

However, we can see that CCS has the correct disassembly in the "Disassembly" window.  Also, we can see that the symbol lookup from the threadx_XDER_611.a library, for function symbol "_tx_thread_schedule() is correct, because it is showing in the "Disassembly."  The only thing is, we DON'T see file content in the source code window.

Now, using readelf, I confirm the symbol cross-reference for funtion _tx_thread_schedule is present in the static library file threadx_XDER_611.a:

readelf also reports that certain data about line numbers in DWARF-3 format:

Also, the source code files are included in the debugger here:

Also, the source files are listed in CCS Debugger:

And, you can see that displaying ASM code generated by CCS HAL works fine. Just reset the processor in debugger and interrupt vectors ASM file is properly loaded by CCS Debugger:

  • 0
    Prodigy 196 points

    Can someone from TI have a look at this?

  • 0
    Prodigy 196 points

    Pinging the thread again. 

    Can someone from TI have a look at this?

  • 0
    Prodigy 196 points

    I was wondering if someone from TI can have a look at this.  It's been a week since the issue was created.

  • 0
    Prodigy 196 points

    Still hoping someone at TI can have a look at this.

  • 0 in reply to Kip Leitner
    TI__Guru 70681 points

    Hi Kip,

    My apologies for the delayed response!

    I worked for some time on this issue, but i am not expert with Threadx RTOS. So, i couldn't find any root cause for your issue.

    I am trying to contact someone expert in this module, i will try to provide my updates ASAP.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 196 points

    Thanks for helping.  This is a big problem for us, since I am debugging threadx Interrupts and context switches. 

    Also:

    • We are currently using Black-Hawk XDS200 debug probe, but will soon be upgrading to black-hawk XDS560v2
    • I tried both Dward-3 and Dwarf-4 for all image files, but CCS still doesn't show source ASM code.
  • 0 in reply to jagadish gundavarapu
    Prodigy 196 points

    And status upgrade yet on this?

  • 0
    Prodigy 196 points

    Hi Jagadish -- Any status update yet on this?

    Since my last request several days ago, I tried a new approach.  Instead of using the ARM FuSa compiler to create a library object, I simply linked in directly all the *.obj files directly into the Code composer studio.

    The exact same problem still exists.

    So, we know that the problem is unrelated to whether the Dwarf-3 input *.obj files are in a static lib, or linked directy into the TI output file from the linker.

  • 0 in reply to Kip Leitner
    Prodigy 196 points

    Hi Jagadish.  This still is not working.  Same Exact problem.  Can you help?

  • 0 in reply to Kip Leitner
    TI__Guru 70681 points

    Hi Kip,

    Can you please make sure that you are following all these things in your project:

    Debug Symbol Format Compatibility:

    Verify that the debug symbols generated by ARM FuSa compiler are compatible with CCS.

    Check if the DWARF version (DWARF-3) from ARM FuSa matches what CCS expects.

    Try generating the ThreadX library with different debug symbol options.

     

    Source Path Configuration:

    Verify the source file paths in CCS match the paths used during ThreadX library compilation.

    Add the ThreadX source directories to the CCS source lookup path.

    Check for any path mapping issues between Windows and development environment.

     

    Project Settings:

    Project -> Properties -> Debug -> Source Lookup Path.

    Add the ThreadX source code directory.

    Enable "Search source files in the build directory".

    Alternative Debug Info:

    Try rebuilding ThreadX library with full debug information (-g3 option).

    Ensure source paths are stored as relative paths in the debug information.

     

    Source File Association:

    In CCS:

    Window -> Preferences -> C/C++ -> File Types

    - Add .s and .S extensions for Assembly files if not present.

     

    Library Build Configuration:

    When building ThreadX:

    Use --debug option

    Include -g flag

    Ensure source file paths are preserved.

    Try using absolute paths:

    Modify the ThreadX build to use absolute paths for source files.

    Update CCS source lookup accordingly.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 196 points

    Hi Jagadish,

    I have already done, many times, everything you suggest -- EXCEPT -- for the first thing you mention, which you call "Debug Symbol Format Compatibility."   Since I do not have the source code for TI's CCS Debugger, I cannot know what it "expects." 

    However, Chat GPT reports that CCS LTS compilers are NOT Compatible.  So there is the answer.  We can stop here.  The problem will never be fixed.  I'll need to find a workaround.  Thanks.

    < CHAT GPT Question >  TI CCS tool chain completely compatible with standard Dwarf3 debugging information specification?

    < CHAT GPT Answer >

    Texas Instruments Code Composer Studio (CCS) has support for DWARF debugging information, but it is not completely and universally compatible with all aspects of the standard DWARF 3 specification. Here’s a breakdown:

    1. DWARF Version Support in CCS

    • TI's compiler tools (like the TI ARM, C2000, or MSP430 compilers) historically used proprietary debug formats, but more recent versions have support for DWARF, primarily DWARF 2 and parts of DWARF 3.

    • Full DWARF 3 compliance is not guaranteed. Support depends on:

      • The specific TI compiler version you're using.

      • The target processor architecture (e.g., ARM, C6000, etc.).

    2. Known Limitations and Considerations

    • CCS integrates well with its own debugger and debug format. When DWARF is used, it may be stripped down or partially implemented, especially for:

      • Complex data types

      • Debugging optimized code

      • Some forms of inlined code and call stack unwinding

    • Third-party tools (e.g., GDB) may not fully understand the debug info generated by TI compilers.

    3. Use Cases for DWARF in CCS

    • If you're generating code in CCS but want to use external tools (like GDB or custom analysis), enabling DWARF can help — but you may hit compatibility issues.

    • CCS is designed primarily to work with TI’s own debug format, which is better supported internally than DWARF.

    4. How to Check DWARF Output

    To see what DWARF version your compiler emits:

    • Use readelf --debug-dump or dwarfdump on an object file.

    • Check your compiler options. For example, in TI ARM compiler, --symdebug:dwarf may be needed to emit DWARF info.

    Summary

    Feature DWARF 3 in CCS
    Fully compliant X No
    Partial support White check mark Yes
    Recommended for CCS debugging X No (prefer TI format)
    Usable with external tools Warning️ Limited — test for compatibility
  • 0 in reply to Kip Leitner
    TI__Guru 70681 points

    Hi Kip,

    I had a discussion with our compiler team regarding this issue; the problem is they can assist only TI ARM compilers however in our case as we are using ARM LTD compiler (ARM FuSa compiler). So, they are even unable to help us with this issue.

    They provided below information regarding TI ARM compiler:

    TI ARM compiler supports both DWARF 3 and DWARF 4. By default, the compiler generates DWARF 3 debug information. 

    The compiler user guide lists all the arm dwarf versions supported.  See table 2-3

    https://www.ti.com/lit/ug/spnu151w/spnu151w.pdf

    --

    Thanks & regards,
    Jagadish.