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.

CCS 5.3x - crash when loading an .out file (built with C6x C/C++ Compiler v7.3.4).



Team,

Please find below instruction to reproduce the CCS crash on CCS  Version: 5.3.0.00090. .out and .obj are built with C6x C/C++ Compiler v7.3.4.

Loading symbols from the output of a relocatable link step crashes CCS 5:

This example is derived from a more complex one that doesn't actually attempt to load symbols from an unrelocated file but exhibits the same problem.

I have the following C file (hello.c):

c_int00() {
   volatile int x = 0;
   for (;;) x ++;
}

I compile it with: cl6x -c -mv6600 hello.c

I link it with: lnk6x -r -mv6600 hello.lnk

where hello.lnk contains:

hello.obj
-o hello.out
MEMORY {
   MEM: origin = 0x800000 length = 0x01000
}

SECTIONS {
   .text:   > MEM
}

This gives me two relocatable outputs: hello.obj and hello.out.

In CCS5 connected to an EVM6678L, I connect to core #0 and select hello.obj with Run/Load/Load Symbols.
This is accepted and behaves as I would expect.

If I do exactly the same thing with hello.out, CCS is _immediately_ blown away (the process is terminated) without any error report.

The test case (.c, .obj and .out) will be available from the below E2E post:
http://e2e.ti.com/support/development_tools/compiler/f/343/t/238493.aspx

Thanks and best regards,

Anthony

  • I didn't see the files in the other thread but I created them based on the text in this thread.  I am not seeing the issue.  Were you able to reproduce?

    I am using a C6657 EVM with the Mezz card on it.  I am going to try the onboard XDS100 as well to see if that makes a difference but it shouldn't since we are only loading symbols thus there should be no target accesses.

    Here are the files that I created based on the info in the thread.  I ran the compiler and link exactly as specified.  If you were able to reproduce can you try my .out and see if it crashes for you.

    4863.hello.zip

    John

  • Testing this out some more.

    Using the XDS100 didn't make a difference.

    I read through the other thread again and the program there is a bit different and has no lnk file.  I tried that as well, no difference.

    I saw in the thread that he was actually using "Add Symbols" vs "Load Symbols", this is actually pretty important since Add Symbols adds the symbols versus unloading the old ones and loading the new ones.  Still works for me.

    Now I think I may have found something.  I use the modules view to see what symbol files I have loaded.  If I expand the functions for hello.obj and click on c_init0 it tries to open the disassembly window and this causes a crash!  So the disassembler seems to be crashing in trying to decode the memory or the debugger itself in reading the memory is crashing.  In my case I have no idea what is in that memory since I have only got symbols in the debugger and no program loaded to the target.  However it should not crash.  CCS is prompting me to send a crash log so hopefully we can figure out what is causing the crash.  I can consistently reproduce that.

    Since Peter is seeing this consistently I am going to see if having the dissassembly open at that address before loading will trigger the crash as well.

    Yes!  If I have the disassembly window open when I add the symbols CCS crashes when adding "hello.out".  I will file a defect and get someone to look at the crash log to see why we are getting the crash.

  • I have filed SDSCM00046176 to track this.  I will let you know if there is a workaround.  Worst case the bug should be fixed in the upcoming 5.4 release if that is the case I will see if we can get you an early build.


    John 

  • Has there been any progress on this?

    Just to pre-empt a possible response about the issue, I have a utility that relocates the object file and generates a new file with a symbol table where all addresses are valid. This new file also crashes CCS5, so it is not simply an address issue.

  • Peter,

    The crash is occurring because there are multiple debug info tables in the file.  This is not supported by CCS.  We can load symbols from executables but a partially linked file doesn't have valid symbol info.  Now you have fixed part of that by creating a utility that updates the symbol table with valid addresses.  Could your utility combine the .debug_infos sections?

    The temporary fix we have in place ignores the second table but what we are really looking at is disabling the ability to load symbols from this type of file as it is not valid.

    John

  • Could you be more explicit as even a trivial object file now has a very large number of sections?

    When you say to 'combine' .debug_infos sections, what exactly do you mean by 'combine'? Is it simply concatenation or is it something more subtle?

    Do you expect all files of the form *.debug_info* to be combined into one section .debug_info, or should all files of the form A.debug_info.B be combined into one file with that name (giving many different *.debug_info.* files)?

    So, should I combine the (many) sections called __TI_DW.debug_info..\u.. into one section called __TI_DW.debug_info..\u..., and combine all the files called __TI_DW.debug_info.$ba... into one section called __TI_DW.debug_info.$ba..., etc.

    Your phrase 'ignores the second table' has confused me as every section whose name contains the text .debug_info. appears several times, not just twice.

    Yet another possibility is that you talking about only those sections called '.debug_info"?

    What about the .debug_line, .debug_info and all the other .debug sections; do they have to be combined too? Does 'combine' mean the same for all of those?

    What about the group tables that reference those sections?

    Something a lot more explict would be appreciated.

    Life was so much simpler when you supported relocatable executables!

    Peter