CODECOMPOSER: Unable to build reproduceable images

Hi Bryan,

Can you provide the 2 projects you are using? We can try to reproduce it on our end. In theory, if the same files are available in both projects, and both projects are using the same compile options, it should generate the same output file.

Thanks,

Ricky

What symbols are at the affected addresses?

Do you have source code that may embed Eclipse variables every time you compile? e.g. date stamps, time stamps, PC id etc.

My employer has an existing NDA with TI so I can send you the project.  Can you provide me your email or FTP link?

The only thing I can decipher from the map file is that some entries within the rodata are arranged differently between the 2 compiled versions.

We don't use __TIME__ and __DATE__ macros.  Our build includes FreeRTOS but I don't see references to those macros in that source code either.

Hi Ricky, can you provide me your email or FTP link?

To narrow the scope of the investigation, I'd like to see the map files from each project.  Please put them in a zip, and attach it to your next post.

Thanks and regards,

-George

Ok thanks George.  I sent them to you via private message.

Bryan McDonald said:

Can you provide the explanation to close out this discussion?

Consider these small example source files.

/* f1.c */
char *string1 = "1234";

/* f2.c */
char *string2 = "4567";

These commands build the files, then show the object file information for the .rodata sections that contain those string constants 1234 and 4567.

C:\examples>tiarmclang -c f1.c f2.c

C:\examples>tiarmobjdump --section-headers f1.o f2.o | findstr rodata
  3 .rodata.str1.46742538633553554961 00000005 00000000 DATA
  3 .rodata.str1.107989333500472712171 00000005 00000000 DATA

Notice how the .rodata section names end with a long auto-generated number.  Among the inputs affecting that number is the full path for the directory to the source file.  Thus, in your build comparison where this is the case ...

Bryan McDonald said:

Copy folder A to folder B on my PC to create two identical folder images.

Those auto-generated numbers are different.

The SECTIONS directive in your linker command file probably has an entry similar to ...

    .rodata > FLASH

This tells the linker to create an output section named .rodata.  It is made up of all the input sections that begin .rodata.  That includes .rodata input sections similar the ones you see above.  This specification imposes no order over the input sections.  In that case, the linker orders them by size, largest to smallest.  What about input sections that are the same size, like the ones above?  This sort has to be stable, so there must be some tie-breakers.  The first tie-breaker is the input section name.  When the input section names are different, they are alphabetically ordered by section name.  Since the .rodata input sections from the folder A build have different names from those same input sections in the folder B build, this tie-breaker results in different orders of these .rodata input sections.  That results in a difference you see when you compare the .rodata output section in the executable files.  That difference propagates throughout the executable.  The places that refer to these strings will have differences related to their different addresses.  Note how none of this difference can be detected by executing the code.     

Thanks and regards,

-George

What exactly is the -fno-unique-string-section-names option doing to prevent the sorting of source files by input section name?

Projects are pulled from Gitlab onto each developer's PC in paths which vary per PC. We've used the CCS Eclipse compiler for 12 months or so and hadn't observed the build mismatches before. Has the compiler always used this sorting method to select the order in which files are linked? and if so, do you feel that our recent observation of this occurrence is coincidental and based on a recent change we may have made to one or more source files? Or is the sorting by input section name new to CCS 12.8?

The sort behavior in the linker never changes.  

Bryan McDonald said:

What exactly is the -fno-unique-string-section-names option doing to prevent the sorting of source files by input section name?

These commands use the same source files from my previous post.  Note the use of -fno-unique-string-section-names.  

C:\examples>tiarmclang -c -fno-unique-string-section-names f1.c f2.c

C:\examples>tiarmobjdump --section-headers f1.o f2.o | findstr rodata
  3 .rodata.str1.1    00000005 00000000 DATA
  3 .rodata.str1.1    00000005 00000000 DATA

Now all the input section names are the same.  To keep the sort stable, the second tie-breaker is used.  The second tie-breaker is the order in which the linker encounters the object file that supplies the input section.  In your case, because the build commands are identical, that means the linker sees the object files in the same order, and thus the input sections are sorted into the same order.

When you changed the version of CCS, you probably changed the version of the compiler at the same time.  Adding a long auto-generated number to the end of the input section name starts with tiarmclang compiler version 3.2.0.LTS.  You probably changed from a compiler version older than 3.2.0.LTS to a compiler version newer than 3.2.0.LTS.

Thanks and regards,

-George