Compiler/RM48L952: C compiler object files changes every time the file is compiled (source file unchanged)

I think we can find the root cause of the difference.  Please use the utility objdiff from the cg_xml package to compare the object files.  If you have trouble interpreting the output, post it here.  Once we know the cause of the difference, possible solutions usually become clear.

Thanks and regards,

-George

Hi,

Installed 2.50.00 package but...

Couldn't get that objdiff to work, in case I understood correctly the objects should be somehow converted to XML and the 'objdiff' is may be capable of doing that either automatically or via some options and that you can use those .exe's without installing any perl stuff...

C:\Program Files (x86)\Texas Instruments\cg_xml\bin>objdiff.exe sl_init.obj sl_init1.obj
Processing sl_init.obj ...

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

I also tried "-ofd6x", "-ofd" and "ofd6x" but no help, first ones gets ignored and result is same as above and latter one throws error:
"'"ofd6x"' is not recognized as an internal or external command,
operable program or batch file.
Running "ofd6x" failed, stopped at script/objdiff.pl line 544."

example shows:

   % perl objdiff.pl file1.obj file2.obj ofd6x

It was also said in objdiff.htm that 'ofd6x' can used for any target and couldn't find other target options...

In case that ofd6x is compiler (which I of course have not installed nor it is in path) I also tried to give the arm c compiler which CCS uses but that does not help:
C:\Program Files (x86)\Texas Instruments\cg_xml\bin>objdiff.exe sl_init.obj sl_init1.obj "C:/ti/ccsv6/tools/compiler/ti-cgt-arm_16.3.0.STS/bin/armcl"
Processing sl_init.obj ...
>> WARNING: -x2 not supported (use -O<n> instead)
>> WARNING: object file specified, but linking not enabled
>> ERROR: no source files, nothing to do
File does not exist:  at XML_TI_OFD.pm line 877.

The error is quite similar as trying to run to compiler with instructions in "gettting started" C:\>ofd6x -x -o=file.xml file.out
C:\Program Files (x86)\Texas Instruments\cg_xml\bin>"C:/ti/ccsv6/tools/compiler/ti-cgt-arm_16.3.0.STS/bin/armcl" -x --output_file=init.xml sl_init.obj
>> WARNING: -x2 not supported (use -O<n> instead)
>> WARNING: object file specified, but linking not enabled
>> ERROR: no source files, nothing to do


Also tried to seek xml from armcl instructions incase I have to do that XML manually and only thing what found was "xml_link_info" but cannot get anything out with that either
C:\Program Files (x86)\Texas Instruments\cg_xml\bin>"C:/ti/ccsv6/tools/compiler/ti-cgt-arm_16.3.0.STS/bin/armcl" -xml_link_info=init.xml sl_init.obj
error: argument to option -x (#) is out of range

C:\Program Files (x86)\Texas Instruments\cg_xml\bin>"C:/ti/ccsv6/tools/compiler/ti-cgt-arm_16.3.0.STS/bin/armcl" -x -xml_link_info=init.xml sl_init.obj
>> WARNING: -x2 not supported (use -O<n> instead)
error: argument to option -x (#) is out of range

C:\Program Files (x86)\Texas Instruments\cg_xml\bin>"C:/ti/ccsv6/tools/compiler/ti-cgt-arm_16.3.0.STS/bin/armcl" -x0 -xml_link_info=init.xml sl_init.obj
>> WARNING: -x0 not supported (use -pn and -pi)
error: argument to option -x (#) is out of range

C:\Program Files (x86)\Texas Instruments\cg_xml\bin>"C:/ti/ccsv6/tools/compiler/ti-cgt-arm_16.3.0.STS/bin/armcl" -x=0 -xml_link_info=init.xml sl_init.obj
>> WARNING: -x0 not supported (use -pn and -pi)
error: argument to option -x (#) is out of range

So most likely at least that -x is not correct option in any form...

I'll have to give up since honestly I have no clue what I should try to do with that cg_xml or how to use it correctly...

I'll put 1 set of those objects here which have that "number change" if that speeds up the process or I need more detailed instructions how to use that cg_xml.
objects.zip

Thanks for the input! I'll tag you answer later "suggested/verified one" but don't do it yet  in order to not show issue would have solvedt, since your "input1" looks to solve 1st stage in the chain.

So the problem is now partially solved. The "--keep_asm" was the key  (there is also setting in GUI for this) and that keeps the c-objects same.

But... The resulting library looks to still change.

There are similar "number changes" after the every object name in the library (didn't look previously what where the actual changes in libraries). There is total on 8 objects in this library. And differences looks to always be after object name in ascii numbers

First difference:

638c1f6fd78f79ae9e1b12050b9faa77.sl_asm_api.obj/ 1505292304  0     0    

vs

638c1f6fd78f79ae9e1b12050b9faa77.sl_asm_api.obj/ 1505292248  0     0    

Second difference (notice that numbers has increase by one)
sl_esm.obj/     1505292305  0     0
vs
sl_esm.obj/     1505292249  0     0

....

....

Eigth (and last) difference
sl_selftest.obj/1505292311  0     0
vs
sl_selftest.obj/1505292256  0     0


So those looks similar "pseudo numbers" as it was in objects files before. Archiver does not look to have practically any configurable GUI options?


Rewinding a bit back and making again libraries without that --keep_asm to really see what kind of differences were initially in libraries -> there was more changes between library as now with --keep_asm, previously there was this kind of changes also which are now disappeared with --keep_asm
1827610.ESM_AppCallback.

vs
2281610.ESM_AppCallback.

and
2606410.$C$L1.$C$L2
vs
2957210.$C$L1.$C$L2

So most likely those numbers are numbers from object files which changed. And  on top of these there are similar differences with numbers after object file names as described beginning of this post, so that --keep_asm removes the differences from library which are inherited from object files but library building itself has some similar "numbers"...

Ps. the problem is not debug information. I have both builds enabled and the issue can be seen also on release build (--symdebug:none)  where object sizes are radically smaller indicating that missing -g really has an effect and output is without debug.

I break your situation down into two related questions.  The initial conditions for both these questions is the same.  The source code, compiler version, build options, build methods, etc are all the same.  Multiple builds are compared. 1. Why are the resulting object files different?  2. Why are the resulting libraries different?  In this post I only address the object file question.

The assembler inserts a symbol, and this symbol's name is the same as the name of the source file.  When you compile with default settings, the name of this file is automatically generated, and thus varies between builds.

Jarkko Silvasti said:

Diff of one object file:
...1515210.$C$L1.$C$L2.$C$L3.$C$
vs
...1260810.$C$L1.$C$L2.$C$L3.$C$

In the first build, the file name is 1515210, and in the second build it is 1260810.  The strings for the names of symbols are stored in a string table.  The string table contains many null terminated strings, one right after the next.  This quote from your first post shows the start of the string table.  The entry for this file name symbol happens to be at the start of the string table.  In version 16.3.0.STS, this automatically generated file name has seven numbers.  In later versions, this file name is a much longer UUID (universally unique identifier).

As you have discovered, building with --keep_asm (or -k for short) avoids this problem, by avoiding the use of the automatically generated name.  That should solve this problem in the short term.  But it is not a long term solution.

TI has never documented that bit identical object files will result from multiple builds with the same conditions.  We don't test for it.  Therefore, it is not wise for you to rely on it.

Jarkko Silvasti said:

Changes causes annoying issues when library is stored in version control and it claims it changed

I suspect this is the core problem you want to address.  Is that right?  Consider a different method.  Instead of keeping object libraries in version control, instead keep the source code, build scripts, the compiler, and any other tools used in the build.  With that, you can reliably re-create the libraries as needed.  And all of those artifacts are completely controlled by you.  It is unlikely you can change to this method in the near term.  So consider using it on your next project.

Thanks and regards,

-George

George Mock said:

TI has never documented that bit identical object files will result from multiple builds with the same conditions.  We don't test for it.  Therefore, it is not wise for you to rely on it.

George Mock said:

I suspect this is the core problem you want to address.  Is that right?  Consider a different method.  Instead of keeping object libraries in version control, instead keep the source code, build scripts, the compiler, and any other tools used in the build.  With that, you can reliably re-create the libraries as needed.  And all of those artifacts are completely controlled by you.  It is unlikely you can change to this method in the near term.  So consider using it on your next project.

For that reason I see that it is much safer/justifiable (and easier to justify the safety of the library) to store also the "tested/validated" copy of the library into version control and use that on releases.

With that said I have a couple of options in mind to "prove" that functionality inside library has not changed.

1) I'll think that modifying the date&time stamps of the objects files is one way (in unix/cygwin "touch -r" and store golden file together with CCS project files and use that file) in case -keep_arm is used and it works with certain compiler version

- This should provide 1:1 library or will it?
- If yes then, is it possible to add build step between compiler & archive to manipulate the files names? Look like it isn't, but could be may circled by leaving acrhiever part empty and do that archieve in post build after you have manipulated files. Maybe this question should be asked in CCS-forum, I'll do that in case this is wrong place for this once I know what are my options and especially if 2) is doable and good enough for our usage.

2) Since 1 is quite kludge, the another option I see is that the person who re-compiles the library is able to "easily" determine whether there is a real functional change or cosmetic change in the library. I'll guess that this is doable by using some "object"-tool to look what is inside library and compare that output to the output of library which is stored into version control, But since this is not my main competence area I would appreciate in case I would get some pointer what tool I should look for (and preferable options for the tool).

The target in case 2) is just to help the designer to notice is the library really changed in or not (basically it looks like that any other changes can be assumed as real changed expect date&time of the object files inside library). There are for example configurable options in headers which may not affect to object output depending on the how other options are configured or the library will be re-compiled because you changed branches in your repository and timestamp of source files changed etc... In case library is not really changed no further actions are needed, but if it changes then we need to take appropriate actions in case we want to take new version into product.

Thanks in advance.

Hi and thank you,

This "objdiff file1 file2 armofd" produced desired result and script says "Files are the same" when diffing libraries so this will be also easy to script automatically check if there is real change. My initial "armcl" which I tried by guessing was wrong tool...

I'll mark answers as verified.