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.

CCSv6 debugger hard crash after loading symbols, no dump file

Other Parts Discussed in Thread: LAUNCHXL2-TMS57012, HALCOGEN

I am attempting to load an ELF file to a TMS570 target, specifically the LAUNCHXL2-TMS57012.  It works OK for a basic hello blinkenlight program, and I've even gotten ARM semihosting to work with the TI debugserver.  But when I attempted to load a more complex program (size of about 300kB), CCS hard crashes.  The crash appears to happen right after "loading program symbols".  No dump files are generated, and nothing appears in the workspace log file.

My Host is Ubuntu 14.04.

Any other ideas for getting some useful information out of CCSv6?

  • Hi Jonathan,
    That is odd, I would expect a dmp file if CCS did indeed crash. Is there anything at all inside: ~/.ti/<ccs install folder name>/0/dmp ?

    Any chance at all you can provide the out file that causes the crash?

    Thanks
    ki
  • I'm traveling and away from my workstation this week, but should be able to provide you the ELF file on Friday 06/26.
  • That'd be great. Thank you.

    Note that if you rather provide the ELF file privately, please start a private conversation with me.

    Thanks
    ki
  • The dump directory contains a single empty subdirectory named 'slow'.

    The attached file doesn't contain anything special.  It is a combination of a standard test program from googletest and a basic HALCOGEN framework for the target processor, linked in the Newlib RDIMON environment (ARM Semihosting).  If I had to guess, I would say that the symbol load system crapped out on one or more of the long mangled C++ symbols within the file.  nm $file | wc -L reports the longest symbol at about 150 chars.

    hello_gunit.out.gz

  • Thank you, this was very helpful. I can reproduce the crash with that out file.

    What exact compiler version are you using? Is it GCC?

    Thanks
    ki
  • I am using a custom build of GCC, derived from the 2015q1 release of GCC 4.9, as packaged by launchpad.net/gcc-arm-embedded. The extent of my customization was to enable big-endian multilibs and then to only build the armv7-r multilibs.

    The code in this .out file was compiled with -marm -mbig-endian -mfpu=vfpv3-d16 -mcpu=cortex-r4f -march=armv7-r -mfloat-abi=hard -Og -g -gdwarf-3 -gstrict-dwarf -ffunction-sections -fdata-sections. C++ code files were also built with -std=c++11 -fasm -U__STRICT_ANSI__ and -fno-exceptions. C code files were also built with -std=c99 -fasm -U__STRICT_ANSI__. Code was linked with -specs=rdimon.specs -Wl,--gc-sections -L. -g -gdwarf-3 -gstrict-dwarf in addition to the architecture flags above.
  • Thanks. I have filed a bug for this issue. Tracking ID is: SDSCM00052064

    ki
  • Can you provide an estimate for when this issue will be resolved?  Is it targeted for 6.2, or 6.1.1 perhaps?

  • 6.2.0 seems most likely but i'll see if we can get it in for 6.1.1. It will be tough due to schedule. I'll have a better idea thursday afternoon after we have our review.

    Thanks
    ki
  • the fix for this bug has been committed to 6.1.1.

    Thanks
    ki
  • Excellent! Is there any way that I can preview CCS v6.1.1 to verify the fix on my end?
  • I think that can be arranged. I'll have more details by tomorrow and let you know then

    Thanks
    ki
  • Hi Jonathan,
    We can provide some binaries that you can drop into your CCS installation that would address the crash.

    But i should provide more details on the situation. Basically the root cause is that the CCS debugger is not correctly processing C++ templated functions, C++ namespaces and static string constants. This is causing the debugger to crash (52064). A fix has been implemented to safeguard against a crash. But this is really more of a workaround since the root causes of the crash still exist. So while you will be able to load the symbols without crashing, they debug experience will not be optimal since some of the processing of the debug symbols as mentioned above are still not processed correctly. This would impact debug visibility to a degree. How much, we're not sure. But if you can try out the fix and give us feedback, that would be great. Please let us know if you are still interested.

    Three new bug IDs have been created to specifically address the three issues I mentioned above:
    52109: static string constants cannot be displayed if gcc stores the string in .debug_str using DW_AT_const_value TAG.
    52110: Debug info about GCC C++ namespaces are not processed correctly
    52111: Debug info about GCC C++ templated functions are not processed correctly

    The work for properly fix these is not trivial. I don't have a specific schedule yet but it would be at best 6.2.0 and possibly later than that.

    ki
  • Ouch.  Well, right now CCS is crashing on an external library and not our code at the moment.  So we are going to temporarily work around the issue on our end by only building debugging information into our "application"-level code, and keeping the debugging information out of the external library.  That seems to be a sufficient work-around with CCS v6.1 as-is, so long as we don't need to go stepping into the external library.

    Thank you for sharing the detailed information about the root cause of the crash at this time.

  • Thanks for the update. If you want the workaround binary, let me know. Though CCSv6.1.1 (which will have the fix) is coming fairly soon so you can always wait for that too.

    Also note that the three issues I mentioned above (the "root cause" issues) will be addressed in CCSv6.2.0

    Thanks
    ki
  • Hi Ki

    When is CCSv6.2.0 targeted for release?

    Cheers2u

    Eddie

  • It should be 1Q 2016.

    Thanks
    ki