• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 52 subscribers
  • Views 783 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/TMS320C6678: Different Linker output

Smriti Verma
Prodigy 140 points
Part Number: TMS320C6678

Tool/software: TI C/C++ Compiler

Why would linker output be different (especially .cinit section) for same code base in different workspace?

.cinit 0 82337c4c 000028f4
82337c4c 00001da6 (.cinit..fardata.load) [load image, compression = rle]
823399f2 00000002 --HOLE-- [fill = 0]
823399f4 00000a22 (.cinit.JPEGIENC_TI_dSect1.load) [load image, compression = rle]
8233a416 00000002 --HOLE-- [fill = 0]
8233a418 00000081 (.cinit..data.load) [load image, compression = rle]
8233a499 00000003 --HOLE-- [fill = 0]
8233a49c 00000012 (.cinit..data:iram.load) [load image, compression = rle]
8233a4ae 00000002 --HOLE-- [fill = 0]
8233a4b0 0000000c (__TI_handler_table)
8233a4bc 0000000b (.cinit..data:uncached:PciMbxDriver.load) [load image, compression = rle]
8233a4c7 00000001 --HOLE-- [fill = 0]
8233a4c8 00000008 (.cinit..bss.load) [load image, compression = zero_init]
8233a4d0 00000008 (.cinit..data:dsptrace.load) [load image, compression = zero_init]
8233a4d8 00000008 (.cinit..data:iram_app.load) [load image, compression = zero_init]
8233a4e0 00000008 (.cinit..far.load) [load image, compression = zero_init]
8233a4e8 00000008 (.cinit.heap_DDR_CACHED_LOCAL.load) [load image, compression = zero_init]
8233a4f0 00000050 (__TI_cinit_table)

.cinit 0 82337c6c 000028f0
82337c6c 00001da2 (.cinit..fardata.load) [load image, compression = rle]
82339a0e 00000002 --HOLE-- [fill = 0]
82339a10 00000a22 (.cinit.JPEGIENC_TI_dSect1.load) [load image, compression = rle]
8233a432 00000002 --HOLE-- [fill = 0]
8233a434 00000081 (.cinit..data.load) [load image, compression = rle]
8233a4b5 00000003 --HOLE-- [fill = 0]
8233a4b8 00000011 (.cinit..data:iram.load) [load image, compression = rle]
8233a4c9 00000003 --HOLE-- [fill = 0]
8233a4cc 0000000c (__TI_handler_table)
8233a4d8 0000000b (.cinit..data:uncached:PciMbxDriver.load) [load image, compression = rle]
8233a4e3 00000001 --HOLE-- [fill = 0]
8233a4e4 00000008 (.cinit..bss.load) [load image, compression = zero_init]
8233a4ec 00000008 (.cinit..data:dsptrace.load) [load image, compression = zero_init]
8233a4f4 00000008 (.cinit..data:iram_app.load) [load image, compression = zero_init]
8233a4fc 00000008 (.cinit..far.load) [load image, compression = zero_init]
8233a504 00000008 (.cinit.heap_DDR_CACHED_LOCAL.load) [load image, compression = zero_init]
8233a50c 00000050 (__TI_cinit_table)

I am using CCS 5.3.0 and C6000 Compiler Tools 7.4.1

  • 0
    TI__Guru**** 238965 points

    While you see more differences in .cinit, those differences are farther away from the root cause of the problem.  For example, .cinit starts at a different address.  This means other sections at lower addresses must be shorter.  The .cinit section is created by compressing initialized sections like .fardata and .data:iram.  Those two sections compress to a different length.

    In the map files from both builds, please carefully inspect the sections .fardata and .data:iram.  I suspect you will see differences.  And those differences are closer to the root cause of the problem.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 140 points
    Thanks for the prompt response.

    .fardata and .data:iram are exactly the same. The only section different other than .cinit is .text. Aside from the different start (address because of difference in size of .text), what can cause difference in size of .cinit? And for that matter .text?

    For .text section , the difference is not consistent i.e; the function with varying size differs from build to build.
  • 0 in reply to Smriti Verma
    TI__Guru**** 238965 points

    For right now, ignore the difference in .cinit.  Focus on the difference in .text.  I suspect that is closer to the root cause.

    Smriti Verma said:
    For .text section , the difference is not consistent i.e; the function with varying size differs from build to build.

    That's quite strange.  I cannot imagine what causes that.  Pick one function you have seen change size.  The larger the difference, the better.  For the source file which contains that function, submit a test case as described in the article How to Submit a Compiler Test Case.  In addition, indicate the name of the function which changes size.  I don't know that I will find the root cause from this test case alone.  But I'm confident it will advance the investigation.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 140 points
    I am unable to "Send a private message" using the site. Is there any other way?
  • 0 in reply to Smriti Verma
    TI__Guru**** 238965 points

    I received the test case you sent through private channels.  Thank you.  

    There is nothing about the source code which explains why the functions change size between builds.  

    But I did notice you use a very old compiler, version 7.4.2.  Among the bugs in that compiler is the one discussed in this thread.  Briefly, the compiler temporary file names may not be unique.  In situations where, due to parallel make, lots of compiles happen at once, this can cause strange problems.  I do not know whether this is the cause of your problem.  But, it is worth upgrading the compiler just to be sure we don't have this issue.

    The fix for that bug first appears in version 7.4.22.  But, since you have to upgrade anyway, you may as well get the last 7.4.x version, which is 7.4.24.  Note the only difference among all the 7.4.x releases is bug fixes.  Everything else is the same.

    So I recommend you get version 7.4.24 from this web site.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Guru**** 238965 points

    Did you upgrade to version  7.4.24?  Did that resolve the problem?

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Guru**** 238965 points

    Since it has been a while, I presume you have resolved the problem.  I'd appreciate hearing how you resolved it.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 140 points
    Upgraded to version 7.4.24 and that seems to have resolve the issue.