• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 1562 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Compiler/TMS320F28335: C2000 Linker Seg Fault

Andrew Bolin
Prodigy 10 points
Part Number: TMS320F28335

Tool/software: TI C/C++ Compiler

I've been fighting an "undefined symbol" error for the past couple of days, and have now shifted it to a linker crash!

(I think that's progress?)

The undefined symbol error appears to actually be a symptom of a problem with allocating memory. It started appearing when I added a bunch of new code to project "B" (new code verified working in project "C"). The undefined symbol errors were related to one of the new classes I was integrating, "Comms_B" in project "B" (again, Comms_B is quite happy to compile & link in project C). But I did add several other things at the same time, none of which trigger any compiler errors, and all of which are confirmed working in project C (project C uses the same chip, but a different linker configuration F28335.cmd file that is incompatible with project B, project B is much bigger than project C)

I placed a few "#ifndef"s around the new class in project B so I can toggle it in/out to test linker settings etc.

Now, with Comms_B out of the picture, I get the below error.

Is this the appropriate place to report this?

Any advice appreciated. I cannot share the code publicly (you don't want to read it anyway), but I think I may be able to get approval to submit to TI for the purpose of troubleshooting.

I'm running Code Composer Studio v7.2 on Linux with compiler version 18.1.1 LTS.

---


**** Build of configuration Debug for project B ****

/home/user/ti/ccsv7/utils/bin/gmake -k -j 4 all -O
Building target: B.out
Invoking: C2000 Linker
"/home/user/ti/ccsv7/tools/compiler/ti-cgt-c2000_18.1.1.LTS/bin/cl2000" -v28 -ml -mt --float_support=fpu32 -Ooff --opt_for_speed=2 --advice:performance=all -g --rtti --diag_warning=225 --diag_wrap=off --display_error_number -z -m"B.map" --stack_size=0x300 --warn_sections -i"/home/user/ti/ccsv7/tools/compiler/ti-cgt-c2000_18.1.1.LTS/lib" -i"/home/user/ti/ccsv7/tools/compiler/ti-cgt-c2000_18.1.1.LTS/include" --priority --reread_libs --diag_wrap=off --display_error_number --xml_link_info="B_linkInfo.xml" --rom_model -o "B.out" "./Bmain.obj" "./B_MainProcess.obj" "./DSP2833x_CodeStartBranch.obj" "/home/user/workspace_v7/EMSLib/DSP2833x_Headers_nonBIOS.cmd" "../F28335.cmd"  -l"/home/user/workspace_v7/BAUTO/Debug/BAUTO.lib" -l"/home/user/workspace_v7/BLib/Debug/BLib.lib" -l"/home/user/workspace_v7/ELib/Debug/ELib.lib" -lrts2800_fpu32.lib -lrts2800_fpu32.lib
<Linking>
warning #10210-D: creating ".esysmem" section with default size of 0x400; use the -heap option to change the default size

INTERNAL ERROR: /home/user/ti/ccsv7/tools/compiler/ti-cgt-c2000_18.1.1.LTS/bin/lnk2000 experienced a segmentation fault

This is caused by a defect in the TI Linker.
TI Customer Support may be able to suggest a workaround to avoid this.

Upgrading to the newest version of the compiler may fix this problem.

Contact TI in the E2E support forums at http://e2e.ti.com under
"Development Tools", "TI C/C++ Compiler".  See the link titled
"Submitting an issue".

We need to see this ENTIRE error message and a complete, reproducible
test case including ALL of the command-line options.
Include all of the object files, libraries, and linker command files
used to link the program.


gmake[1]: *** [B.out] Error 1
>> Compilation failure
makefile:151: recipe for target 'B.out' failed
gmake: *** [all] Error 2
makefile:142: recipe for target 'all' failed

**** Build Finished ****

  • 0
    TI__Guru**** 232880 points

    Please send in a test case which allows us to reproduce this behavior.  In cases like this, we often ask for the entire CCS project.  But you mention ...

    Andrew Bolin said:
    I cannot share the code publicly (you don't want to read it anyway), but I think I may be able to get approval to submit to TI for the purpose of troubleshooting.

    Given that ... In this particular case I think we can get away with not having the entire project.  Please zip these files up ...

    Bmain.obj
    B_MainProcess.obj
    DSP2833x_CodeStartBranch.obj
    /home/user/workspace_v7/EMSLib/DSP2833x_Headers_nonBIOS.cmd
    ../F28335.cmd
    /home/user/workspace_v7/BAUTO/Debug/BAUTO.lib
    /home/user/workspace_v7/BLib/Debug/BLib.lib
    /home/user/workspace_v7/ELib/Debug/ELib.lib

    Send that just to me.  Here's how.  Hover your mouse over my screen name or avatar.  A box will pop up. Click on Send a private message. In the message compose interface which comes up, use the paper clip icon to attach the zip file.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 60 points
    Thanks George, I will gather those files and send them over to you.
    Assuming there is some agreement from TI to keep the code confidential, I have been told that I can submit the source if required.
  • 0 in reply to Andrew Bolin0
    TI__Guru**** 232880 points

    Thank you for sending in a test case.  I cannot reproduce the exact same problem.  But I did see an unusual diagnostic.  So I filed CODEGEN-4721 in the SDOWP system to have this investigated.  You are welcome to follow it with the SDOWP link below in my signature.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 60 points
    Hi George,
    There is no update on the incident report (the report is also tagged as version 16.9.1, but the result is the same in all compilers I have installed from 16.9.1 to 18.1.1). I note that this thread is tagged as "TI Thinks Resolved", but our project is still stalled.

    I have experimented with the linker .cmd file further and refactored the code a little (a colleague said they had strange behaviour which they attributed to too much code in header files). Depending on configuration I can get an "unresolved symbol" error, or using the "Release" build configuration I get a seemingly successful build but then the IDE crashes when trying to transfer the program to the chip.

    Is there any guidance that anyone can give me, or can I submit the full code (under some kind of confidentiality agreement) for further diagnostics?

    To restate, my team's commercial project is unable to proceed because of this problem.
  • 0 in reply to Andrew Bolin0
    TI__Guru**** 232880 points

    Andrew Bolin0 said:
    can I submit the full code (under some kind of confidentiality agreement) for further diagnostics?

    It would be ideal if I reproduced the exact same linker crash you show.  And for that I suspect we need the entire CCS project.  Please see the article Project Sharing for how to create the zip file. Then send that to me by private message, just as you did the last test case.

    As for a confidentiality agreement ... I have never negotiated such an agreement.  I don't know what all is involved.  Though I am vaguely aware it requires lawyers, forms you'd rather not read, signatures from officers of both companies, and all manner of things like that.  In case you can't tell, I take a dim view of it all.

    Rather, think of it this way.  We are well aware of the trust you place in us when you send us your code.  Suppose something somehow gets out, and it is our fault.  Agreement or not, we would never see another test case.  This would ruin our business.  Believe me, we take this very seriously.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 60 points

    Hi George,

    I share your feelings about negotiating with lawyers etc.

    If you could just say words to the effect of "your code will be used only for troubleshooting this problem and it won't go outside TI" then that's all I need.

    (I appreciate you've strongly implied this above but our legal people need an explicit statement... sorry)

    Cheers,

    Andrew.

  • 0 in reply to Andrew Bolin0
    TI__Guru**** 232880 points

    Of course.  Your code will be used only for troubleshooting this problem and it won't go outside TI.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 60 points
    Thanks. PM sent with code attached.
  • 0 in reply to Andrew Bolin0
    Prodigy 60 points
    OK, after some further experimentation I can say that at present the Seg Fault is only occurring on Linux.
    On Windows, I can compile, load, and run the program!

    Does this imply there is a bug in the Linux build of the linker?
  • 0 in reply to Andrew Bolin0
    TI__Guru**** 232880 points

    Thank you for sending another test case.

    Andrew Bolin0 said:
    I can say that at present the Seg Fault is only occurring on Linux.

    I can reproduce that crash.

    Andrew Bolin0 said:
    Does this imply there is a bug in the Linux build of the linker?

    Yes.  I updated CODEGEN-4721 to add the recent test case.  As before, you are welcome to follow it with the SDOWP link below in my signature.

    Is it practical for you to perform the build on Windows?  Is your project still at production stop?

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 60 points

    George Mock said:

    Yes.  I updated CODEGEN-4721 to add the recent test case.  As before, you are welcome to follow it with the SDOWP link below in my signature.

    Thanks. At least we seem to have narrowed down the problem.

    George Mock said:

    Is it practical for you to perform the build on Windows? 

    It's not ideal, but I can deal with it.

    George Mock said:

    Is your project still at production stop?

    No, this allows me to proceed. Thanks for the assistance.