• State Resolved
  • Locked Locked
  • Replies 22 replies
  • Subscribers 54 subscribers
  • Views 2807 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.

Why are CCS v.5.5 Binary Sizes Different on Two PCs?

Jim Warren
Prodigy 250 points

Hello,

 

We are using Code Composer Studio version 5.5 with the Code Generation Tools Compiler version 6.2.10.  We have two PCs where on one machine we run a build with the IDE, and on the other, from the command line.  These are identical source, identical files included, and identical parameters are used for compile settings.

 

The only difference is the binary generated from the PC using a command line driven build is about 10 kilobytes larger than the PC using the IDE to build the same.  Naturally the checksums of each do not match which is what flagged our attention for this.

 

Can you offer any suggestions as to why we are experiencing this, given all the similarities between the two PC’s?

 

-Jim

  • 0
    TI__Guru* 84225 points
    Are the projects on the two different machines installed in directories that have identical names? Various path names are embedded in the debug information, and if one path is longer, one of the executable object files will be larger.

    The executable object file size does not reflect the actual size of the application when it sits on the target; is there a difference in target footprint between the executable object files?
  • 0
    TI__Guru**** 232900 points

    An object file contains much information that is not loaded (flashed, or whatever) to the target system.  This can be meta-data such as time stamps or symbol tables, and it can be debug information.  The debug information contains things like the full path to where the source code is located.  That is likely to be different between a command line build and a build performed from within CCS.  

    To verify the target image matches, please consider using the utility objdiff from the cg_xml package.

    Thanks and regards,

    -George

  • 0 in reply to Archaeologist
    Prodigy 250 points
    Hello and thank you for the speedy reply.

    Yes, you are correct. The two PCs have completely different root directory paths for where the source is located and built. We are (at least for now), using a "ROM" build (instead of "Debug" or "Release" types). Correct me if I'm wrong, but do the ROM type builds have debug info / data built into them by default? If so, then that would explain the different size of binaries between machines.

    In order to compare the real "size on target", is there a menu option in the CCS GUI where I could view actual size taken up by the binary on the target, or a utility to strip off the debug info for the "ROM" type executable so I may compare "apples to apples"?

    -Jim
  • 0 in reply to George Mock
    Prodigy 250 points
    Hello George,

    Thank you for the speedy reply.

    Regarding the "cg_xml" package, is that just run from the command line for a given ".out" binary? Or is it used in the CCS 5.5 GUI?

    -Jim
  • 0 in reply to Jim Warren
    Guru 92251 points

    Jim Warren said:
    Or is it used in the CCS 5.5 GUI?

    There was a Code Generation Tools XML Processing Scripts Plug-in for CCS created for CCSv4 but the plug-in isn't supported in CCSv5 or CCSv6 (see Installation and Requirements).

    Therefore, you have to call the utilities in the cg_xml package from the command line.

  • 0 in reply to Chester Gillon
    Prodigy 250 points
    That's ok. I actually tried it but I got this error:

    C:\>objdiff "C:\Program Files (x86)\Texas Instruments\BS\ChargerApp.out" "C:\Program Files (x86)\Texas Instruments\Jim\ChargerApp.out"
    Processing C:\Program Files (x86)\Texas Instruments\BS\ChargerApp.out ...

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


    So when I look at the usage, I notice I need an "ofd cmd" parameter:
    C:\>objdiff /?
    Usage: objdiff.exe [options] <file1> <file2> [<ofd cmd>]

    C:\>


    I did not see any description of this "ofd cmd" parameter (or the options for objdiff itself) in either the "getting_started.txt" or "overview.ppt" files in the installation.

    Where may I find this information? Also, I am using Windows 7, Service Pack 1, so if you know any specific temp directories for this OS that I need to make writeable, that would be most helpful as well...

    -Jim
  • 0 in reply to Jim Warren
    Guru 92251 points

    Jim Warren said:
    In order to compare the real "size on target", is there a menu option in the CCS GUI where I could view actual size taken up by the binary on the target, or a utility to strip off the debug info for the "ROM" type executable so I may compare "apples to apples"?

    The linker .map file produced by the linker is a text file which contains the size of the memory regions used on the target, along with the addresses and size of the section allocated on the target.

    By performing a textual comparison of the linker .map files between the two builds you should be able to size if the actual size taken up by the binary is different.

    [With CCS 6 there is also a Memory Allocation View which displays the size allocated on the target, as extracted from the linker output, but can't remember if the Memory Allocation View is available in CCS v5.5]

  • 0 in reply to Chester Gillon
    Prodigy 250 points
    I did observe when I performed that comparison previously, under the "Memory Configuration" section of each binary's ".map" file, the flash sectors that store the image show more used in binary 1 than binary 2.

    When looking at the "Used" and Unused" values for each binary, is the debug info related to different build paths on different PCs excluded, implying that the actual binaries are different?

    -Jim
  • 0 in reply to Jim Warren
    Guru 92251 points

    Jim Warren said:
    Where may I find this information?

    In the root of the cg_xml installation there should be an index.htm file which allows you to navigate to the documentation for the objdiff.pl command, where the documentation is in the docs/ofd/objdiff.htm file in the installation.

    The "ofd cmd" parameter is the name of program to create the XML version of the object file.

  • 0 in reply to Jim Warren
    Guru 92251 points

    Jim Warren said:
    When looking at the "Used" and Unused" values for each binary, is the debug info related to different build paths on different PCs excluded, implying that the actual binaries are different?

    The debug information is excluded from the flash sectors that store the image.

    However, if the code uses the __FILE__ pre-processor directive to initialize strings in the target  then the __FILE__ inserts a path string into the target image which can change size of the target image according to the relative path-lengths of the source code.

    It does sound like the two images in the target are actually different, which objdiff should be able to help to track down the cause.

    Jim Warren said:
    I did observe when I performed that comparison previously, under the "Memory Configuration" section of each binary's ".map" file, the flash sectors that store the image show more used in binary 1 than binary 2.

    The .map file also contains the global symbols sorted by symbol address. By comparing the global symbols sorted by symbol address, and finding the first different symbol address might also help to track down the preceding symbol which has changed size.

  • 0 in reply to Chester Gillon
    Prodigy 250 points
    In order to look for the fastest solution (because I tried using "ofd2x" (we use the C2000 MCU) as an OFD Command but it was an unrecognized command), and since we do use the "__FILE__" preprocessor directive quite a bit, would it make more sense just to do a quick and dirty build on each PC using the exact same root directory path names? (Which is easy to do now).

    That should give a red flag if there is still a difference when trying that, shouldn't it?

    -Jim
  • 0 in reply to Jim Warren
    Guru 92251 points

    Jim Warren said:
    (because I tried using "ofd2x" (we use the C2000 MCU) as an OFD Command but it was an unrecognized command)

    For the C2000 MCU the OFD command to use is ofd2000, which is in the bin directory of the C2000 compiler installation.

    Jim Warren said:
    That should give a red flag if there is still a difference when trying that, shouldn't it?

    Agree that a quick and dirty build on each PC using the exact same root directory path is a good way of identifying if the __FILE__ pre-processor directive is the (only) cause of the differences.

  • 0 in reply to Chester Gillon
    TI__Guru* 84225 points
    Please note that the executable object file will never be binary-identical because there is other meta information in the object file. cg_xml is the recommended way to get an apples-to-apples comparison.
  • 0 in reply to Archaeologist
    Prodigy 250 points

    Ok.  Could you elaborate on what the "meta information in the object file" is?

    Also, does this imply that binary sizes (and check sums) can vary between builds on the same PC, or, binary sizes and check sums can vary between two different PC builds using the same code, settings, and absolute path names?

    -Jim

  • 0 in reply to Jim Warren
    TI__Guru* 84225 points
    They can differ on the same PC. The meta information may include the date and time, as well as the names of temporary files used during the compilation. cg_xml knows how to ignore such differences.
  • 0 in reply to Archaeologist
    Prodigy 250 points
    Good to know. Just to clarify, is metadata (such as this or otherwise) still present on the binary when making a Release build (I.e., without debug info)? If so, can it be stripped away from the binary?

    -Jim
  • 0 in reply to Jim Warren
    TI__Guru* 84225 points
    Some of it can, some of it cannot. For the concerns of this discussion, there is no difference between Release and Debug builds. If you use strip2000, you'll eliminate the debugging information, which contains the file names for temporary files. However, you can't remove metadata like the number of sections or their starting address in target memory from the object file. I'm not sure whether stripped object files build on the same PC will be binary-identical, but I suspect not.
  • 0 in reply to Archaeologist
    Prodigy 250 points
    Given those facts, is the "objdiff.exe" script in the "cg_xml" utility then the best option to ensure that both binaries are truly "identical"?

    -Jim
  • 0 in reply to Jim Warren
    TI__Guru**** 232900 points

    Yes.  -George

  • 0 in reply to George Mock
    Prodigy 250 points
    Thank you George. Can you tell me the correct syntax to use the "strip 2000" utility?

    I tried this:
    objdiff "C:\filePath\Binary1.out" "C:\filePath\Binary2.out" ofd2000 strip2000

    But it was unsuccessful.

    I was able to get the objdiff utility to work just fine with the OFD utility by itself:
    objdiff "C:\filePath\Binary1.out" "C:\filePath\Binary2.out" ofd2000

    -Jim
  • 0 in reply to Jim Warren
    TI__Guru**** 232900 points

    Jim Warren said:
    Can you tell me the correct syntax to use the "strip 2000" utility?

    It is yet another command line utility that comes with the compiler tools.  It is documented in the C28x assembly tools manual.  Do not use it in combination with objdiff.

    Jim Warren said:
    I was able to get the objdiff utility to work just fine with the OFD utility by itself:

    objdiff "C:\filePath\Binary1.out" "C:\filePath\Binary2.out" ofd2000

    That is typical usage of objdiff.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 250 points
    Thank you George. Different absolute file path names was our issue. Once we all built using the same path names, we were able to confirm the same binaries with the objdiff tool.

    Cheers!

    -Jim