CCSv6 debugger hard crash after loading symbols, no dump file

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.

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

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