• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 53 subscribers
  • Views 1790 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.

What symbols are created for a cpp file?

Roman Karlstetter
Intellectual 560 points

Hi,

I'm having a problem with a project that has the following layout (simplified):

mysource.cpp
subfolder/mysource.cpp

both of these files have the same modification time. When I link the object files that are created by compiling the two *.cpp files, I get a linker error saying something along the lines of:

error #10056: symbol "__sti___9_mysource_cpp_edc9f1c5" redefined: first defined in "subfolder/mysource.obj"; redefined in "mysource.obj"

After I touch one of the files (changed file modification time), the error disappears. It seems that the compiler creates these symbols and uses a hash of the file modification time (and possibly the file name). Renaming one of the files solves the issue, too. Nevertheless, I think this behavior is not really how it should be, perhaps the hash should include the complete path to the file. What is the reason for the symbol being generated?

Kind regards,

Roman

PS: This happens for TI cgt 7.4.8
PPS: This happens only in EABI mode, COFF ABI does not have this problem

  • 0
    TI__Guru* 84285 points

    I can't comment on the symbol collision, but I can tell you that functions named __sti__whatever are generated by the compiler to execute the constructors for global C++ objects before main begins.

  • 0
    TI__Guru**** 249890 points

    Please post mysource.cpp.  We can build a small test case which duplicates the problem.  But it doesn't do anything.  We don't see how this problem can occur in code that is actually useful.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 560 points

    Thank you for your rapid feedback,

    I created a minimal example project that exposes the problem and actually does something useful. We use the c++ global initialization feature to register "modules" in our application. In the main function, these modules are initialized in a specific order (part of the module description, initalization is not part of the example to keep it simple).

    Here is the zip, just make sure the mysource.cpp files have the same modification time, compile all cpp-files in --abi=eabi mode and link the objects together.

    7752.TIsymbolcollision.zip

    I hope this helps you to understand that code like this is actually very useful, we rely on it everywhere in our application.

    Best regards,

    Roman

  • 0 in reply to Roman Karlstetter
    TI__Guru**** 249890 points

    Thank you for submitting a realistic test case.  I can reproduce the problem.  I filed SDSCM00050703 in the SDOWP system to have this investigated.  Feel free to follow it with the SDOWP link below in my signature.

    I discovered another unusual circumstance is required to trigger the bug.  The current directory in effect must be the same for both compiles.  That is, this causes the problem ...

    % cl6x subfolder/mysource.cpp
% cl6x mysource.cpp

    However, this does not ...

    % cd subfolder
% cl6x mysource.cpp
% cd ..
% cl6x mysource.cpp

    This gives you another way to work around the problem.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Intellectual 2630 points

    We investigate this bug and we conclude it is caused by some design issues in our parser. It will take a long time to get this fixed. 

    In the mean time, here is a work around to address this issue. There should be no side effect to apply this work around.

    In one of the name clash files, add this line before "static int var = the_user_function("argument");"

    int some_unused_variable_name = 0;

    This will cause the parser to give different name to the file level static int variable, and it can help avoid the name clashes in the linker.

    Please try it and if there is any problem, please let us know.

    Thanks,

    Wei

  • 0 in reply to Wei Zhao
    Intellectual 560 points
    I justed wanted to quickly add that the variable has to be in global scope, adding it inside a namespace does not work.

    Any news regarding a fix for the problem?
  • 0 in reply to Roman Karlstetter
    TI__Guru**** 249890 points

    Roman Karlstetter said:
    Any news regarding a fix for the problem?

    Unfortunately, no.  -George