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

CCS/AM5728: Windows/Linux CCS Output Differences

Joshua Trejo
Prodigy 90 points
Part Number: AM5728

Tool/software: Code Composer Studio

Hi, 

Our team is developing for a BeagleBoard x15 using CCS v7.4.  Our main development environment is on Windows 7 (which we have developed on for 1+ years) but now we are bringing up a CI system with Ubuntu 18.04 for reproducible builds. We've replicated our Windows development environment on Ubuntu (CCS v7.4, RTOS SDK (v03.02.00.05), compiler GNU Linaro v6.3.1).

The problem we are having is that in Linux, with the same compiler and matching source versions, we are getting a different image (slightly larger) than what we're getting in Windows.  As a result, this fails our post-build activities - we have not yet profiled our system's performance for differences.

Has any one experienced this before?

Thanks in advance!

  • 0
    TI__Guru**** 232790 points

    Joshua Trejo said:
    we are getting a different image (slightly larger)

    Exactly how do you measure the difference?  For now, I presume the amount of target memory used is different.  In particular, I presume you are not looking at the size of the final executable object file.

    I cannot explain what is happening, but I can suggest ways to better understand the cause of the difference.

    If you suspect the difference is in the size of the code, then I suggest you use the technique described in the article Find Source of Code Size Increase, with one change.  You are not interested in finding the functions which changed size the most.  You are interested in finding all the functions which changed size.  Once you know that, focused investigation of those functions might reveal something useful.

    If the difference is not in the code size, then I suggest you compare the final executable files with utility objdiff from the cg_xml package.  I'm not sure what it will find.  But whatever that is, it is worth more investigation.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 90 points

    Hi George, 

    Thanks for your reply!

    We can't produce the final application image because the post-build image generation tools fail. The files where we see the difference are the .out files.

    We don't suspect the code size to be the issue because we are cloning the repository. So the code, configuration, etc. are exactly the same.

    We tried using the `objdiff` tool with the .out files, but it was crashing. The same thing was occurring when giving the tool the same application image (good one built on Windows).

    The output was:

    not well-formed (invalid token) at line 1, column 4, byte 4 at XML/Parser.pm line 187

    To make sure we're not feeding the wrong type of file, could you clarify "final executable"?

  • 0 in reply to Joshua Trejo
    TI__Guru**** 232790 points

    I owe you an apology.  I overlooked the fact that you use the GNU ARM compiler, and not the TI ARM compiler.  I should not have referred you to the article about code size increase.  That technique only works with TI compilers.

    While objdiff was first developed for use with TI compilers, it does work with code produced by the GNU ARM compiler.

    Joshua Trejo said:
    not well-formed (invalid token) at line 1, column 4, byte 4 at XML/Parser.pm line 187

    You're probably not invoking it correctly.  The documentation for cg_xml is in the package.  The root directory has a file named index.htm.  Load that file into your favorite web browser.  A common mistake is not putting the OFD command (armofd in your case) last on the command line.

    Joshua Trejo said:
    To make sure we're not feeding the wrong type of file, could you clarify "final executable"?

    The file produced by the linker.  It is named with the linker option -o, and usually (though not always) has the extension .out.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 90 points

    Thanks for the tip on the documentation. We were able to invoke the command correctly now. Here’s the output:

    enguser@enggitlab1:~/ti/cg_xml$ ~/ti/cg_xml/bin/objdiff --verbose ~/good.out ~/GitlabRepo/Applications/AM572x/MPU0/Debug_System_Controller/AM572x_MPU0.out ofd6x
    Processing /home/enguser/good.out ...
    Processing /home/enguser/GitlabRepo/Applications/AM572x/MPU0/Debug_System_Controller/AM572x_MPU0.out ...
    Comparing files ...

    ======================================================================
    Comparing Sections : section = .text
    ======================================================================
    Raw data is different
    Byte 714932 is different
    /home/enguser/good.out: 0x68
    /home/enguser/GitlabRepo/Applications/AM572x/MPU0/Debug_System_Controller/AM572x_MPU0.out: 0x70
    Byte 777692 is different
    /home/enguser/good.out: 0x8
    /home/enguser/GitlabRepo/Applications/AM572x/MPU0/Debug_System_Controller/AM572x_MPU0.out: 0x4
    Byte 777693 is different
    /home/enguser/good.out: 0x60
    /home/enguser/GitlabRepo/Applications/AM572x/MPU0/Debug_System_Controller/AM572x_MPU0.out: 0x41
    Byte 777694 is different
    /home/enguser/good.out: 0x8d
    /home/enguser/GitlabRepo/Applications/AM572x/MPU0/Debug_System_Controller/AM572x_MPU0.out: 0x48
    Byte 777695 is different
    /home/enguser/good.out: 0xe5
    /home/enguser/GitlabRepo/Applications/AM572x/MPU0/Debug_System_Controller/AM572x_MPU0.out: 0xe3
    Byte 777696 is different
    /home/enguser/good.out: 0x4
    /home/enguser/GitlabRepo/Applications/AM572x/MPU0/Debug_System_Controller/AM572x_MPU0.out: 0x8
    Byte 777697 is different
    /home/enguser/good.out: 0x41
    /home/enguser/GitlabRepo/Applications/AM572x/MPU0/Debug_System_Controller/AM572x_MPU0.out: 0x60
    Byte 777698 is different
    /home/enguser/good.out: 0x48
    /home/enguser/GitlabRepo/Applications/AM572x/MPU0/Debug_System_Controller/AM572x_MPU0.out: 0x8d
    Byte 777699 is different
    /home/enguser/good.out: 0xe3
    /home/enguser/GitlabRepo/Applications/AM572x/MPU0/Debug_System_Controller/AM572x_MPU0.out: 0xe5
    Byte 788517 is different
    /home/enguser/good.out: 0x20
    /home/enguser/GitlabRepo/Applications/AM572x/MPU0/Debug_System_Controller/AM572x_MPU0.out: 0xc0
    Byte 788521 is different
    /home/enguser/good.out: 0xc0
    /home/enguser/GitlabRepo/Applications/AM572x/MPU0/Debug_System_Controller/AM572x_MPU0.out: 0x20
    Byte 788533 is different
    /home/enguser/good.out: 0x20
    /home/enguser/GitlabRepo/Applications/AM572x/MPU0/Debug_System_Controller/AM572x_MPU0.out: 0xc0
    Byte 788537 is different
    /home/enguser/good.out: 0xc0
    /home/enguser/GitlabRepo/Applications/AM572x/MPU0/Debug_System_Controller/AM572x_MPU0.out: 0x20
    ======================================================================
    Comparing Sections : section = .vecs
    ======================================================================
    Raw data is different
    Byte 32 is different
    /home/enguser/good.out: 0x68
    /home/enguser/GitlabRepo/Applications/AM572x/MPU0/Debug_System_Controller/AM572x_MPU0.out: 0x70
    ======================================================================
    Comparing Sections : section = .c_int00 : elf32_shdr
    ======================================================================
    Differences: /home/enguser/good.out /home/enguser/GitlabRepo/Applications/AM572x/MPU0/Debug_System_Controller/AM572x_MPU0.out
    sh_addr: 0x80001168 0x80001170
    ======================================================================
    Comparing Sections : section = xdc.meta : elf32_shdr
    ======================================================================
    Differences: /home/enguser/good.out /home/enguser/GitlabRepo/Applications/AM572x/MPU0/Debug_System_Controller/AM572x_MPU0.out
    sh_size: 0x128 0x130

    Files are different

    I think the bottom 3 sections are interesting. The .vecs section has a difference of one byte which seems to determine the offset in the next section (.c_int00). Presumably, this throws off the .text section.

    I verified the linker options are exactly the same, so I’m not sure how this is happening. Maybe these differences mean something to you? Let me know if there’s anything else you’d like me to try.

    Thanks!

  • 0 in reply to Joshua Trejo
    TI__Guru**** 232790 points

    I suggest you pick one difference and try to explain it.  With any luck, that will quickly lead to the root cause.

    This one looks like a good place to start ...

    Joshua Trejo said:
    ======================================================================
    Comparing Sections : section = .vecs
    ======================================================================
    Raw data is different
    Byte 32 is different
    /home/enguser/good.out: 0x68
    /home/enguser/GitlabRepo/Applications/AM572x/MPU0/Debug_System_Controller/AM572x_MPU0.out: 0x70

    The byte 32 means the difference occurs 32 bytes after the start of the section .vecs.  To know the address on the target, find the base address of the .vecs section, and add it.  You can find that address in the linker map file.  

    To understand what this difference means, you have to work out how this byte is interpreted by the system during execution.  One guess: It might be one byte from a 32-bit value that is used as the address of a function.

    Thanks and regards,

    -George

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

    Please let us know what you found out regarding the difference I discussed in my last post.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 90 points
    Apologizes for the delayed response. Using your suggestions we found that the root cause was our error - we have fixed and are proceeding on. Thank you for your help!