Inconsistent Build Output

When you say the build output is different between the builds, exactly what is the difference and how are you comparing the files to determine this difference?

First, I am assuming the build environment is exactly the same for all the builds (ie version of CCS and compiler tools, build options, etc).  The .out file generated by CCS contains lots of meta-data, such as debug information, that is not loaded to the target. Please see this post for an explanation and a utility named objdiff that can be used to compare executables. This utility ignores meta-data that is not loaded to target and should be a more accurate way of determining if your build outputs really differ or not.

If you search the forums (mostly Compiler forum) for objdiff you will find quite a few threads on this topic of comparing build outputs. Hope this helps.

Thanks for the information.

We use Hex Workshop and Notepad++ for comparing files.

The build environments are identical.

The tool you suggest looks useful for avoiding the meta data problem, just as soon as I can get it through our IT department!.

We have compared binary files generated from the .out files too and generate CRCs, so we are sure there is a difference in the executable. The comparisons show a multitude of differences, some individual words, some large blocks. If you're looking for more detail, let me know and I'll decipher what I can.

Phil.

Phil - Are you using BIOS? And if so, is Log_info being used in your code?

No, we have no operating system.

Here's a snip from two map files, the indented names can be seen in a different order:

GLOBAL SYMBOLS: SORTED BY Symbol Address

address    name
--------   ----

0002b774   PressSignalConditioner_applyCalibrationCorrection
0002bb04   PressSignalConditioner_applyFiltering
0002beb8           TMS570_RTIM_CMP_controlDmaInterrupt
0002c014           TMS570_RTIM_CMP_getCompareInterruptState
0002c054  TMS570_RTIM_CMP_intialise
0002c0c8  TMS570_RTIM_CMP_bind
0002c1f4  TMS570_RTIM_CMP_configure
0002c278  TMS570_RTIM_CMP_getValues
0002c2f4  TMS570_RTIM_CMP_controlCompareInterrupt
0002c480  TMS570_RTIM_CMP_controlLocalAndGlobalPendingStates
0002c58c           TMS570_RTIM_CMP_getDmaInterruptState
0002c5cc   TMS570_RTIM_CMP_refreshLocalPendingStates
0002c6e0   TMS570_RTIM_CMP_runRegisterChecks

0002b774   PressSignalConditioner_applyCalibrationCorrection
0002bb04   PressSignalConditioner_applyFiltering
0002beb8   TMS570_RTIM_CMP_intialise
0002bf2c   TMS570_RTIM_CMP_bind
0002c058   TMS570_RTIM_CMP_configure
0002c0dc   TMS570_RTIM_CMP_getValues
0002c158   TMS570_RTIM_CMP_controlCompareInterrupt
0002c2e4           TMS570_RTIM_CMP_controlDmaInterrupt
0002c440   TMS570_RTIM_CMP_controlLocalAndGlobalPendingStates
0002c54c           TMS570_RTIM_CMP_getDmaInterruptState
0002c58c           TMS570_RTIM_CMP_getCompareInterruptState
0002c5cc   TMS570_RTIM_CMP_refreshLocalPendingStates
0002c6e0   TMS570_RTIM_CMP_runRegisterChecks

The two maps were generated from the same project but located one folder down, i.e.:

U:\Build_Experiment\Build\ and

U:\Build_Experiment_Down_One_Folder_Level\Build_Experiment\Build\

Phil,

Can you attach the complete map files (both versions)? Also could you copy and paste the full output in the CCS build console to a text file (this will show the exact build options and order in which files are passed to linker) for both builds and attach those here as well?

Maps and console output attached.

Slightly different builds, unfortunately. These were easily available. If you need it exactly the same, barring the location, let me know. And the start of the build is not in the console output. Again, let me know if you need this.

Many thanks,

Phil.

Thanks Phil.

Ideally, yes we want to look at the map files and build output for the exact same build, barring the location, as that is what we want to comapre for differences. Would you mind sending these when you get a chance?

Also I see that the file ccsLinker.opt is being passed as input to the linker. This file would contain the list of object files that get passed to the linker. So could you also attach this file for both builds? Also would be helpful if you could attach the final .out generated from both builds, so we could run the objdiff utility on those as well. Thanks!

Re-built.

Zipped up ccsLinker.opt, full build logs, .map & .out files attached.

I'm out of the office until Monday but let me know if there is anything else that will help.

Many Thanks,

Phil.

P.S. Just built these two with Code Composer 5.1.0.09000. The output is the same, map and binary, so it looks like an issue with 5.5.0.00077.

Phil,

With the help of a colleague I did some analysis on your files. Here is a summary of what we did and observed:

1) Ran objdiff on the two .out files which reported that there were differences in the .cinit and .text sections
2) Ran armdis.exe on the two .out files to look at disassembled output - this is something you can run as well for a comparison, and has useful information that can be used for analysis
3) Focusing on the differences in the .text section, we looked at where the first set of differences were as reported by objdiff, and correlated that back to the disassembled output. It turned out to be at address 0x24860, which from looking at the disassembled outputs is indeed different (one is calling SWutils_getLeastSignif16bitsFrom32bits while the other is calling SWutils_getMostSignif16bitsFrom32bits).
4) While still comparing the disassembled output, noticed that at address 0x2483c the function in one of them is reduceToLeastSignif16bits while in the other it is reduceToMostSignif16bits

I can't explain the reason for this difference, but according to the map file, this is coming from SDD_Wkr.obj. The next step would be to drill into why this object file from the two builds is different.

As a next step, please do the following:

1) Preprocess the source file SDD_Wkr.c from both build locations. This wiki page tells you how to preprocess a source file
2) Rename the preprocessed file to .c extension, and compile it with the same build options as is used for the project build (this might be easier to do on a command prompt as it is only the compile step we need)
3) Compare the SDD_Wkr.asm file generated by both builds to see if there are differences and where they are

If the two assembly files indeed have differences, please send us the two proprocessed source files so we can build them ourselves and analyze further to determine if there is a bug.

Hi.

I carried out the steps you suggested. The results are attached.

There are 5 files:

1. manual_pp.jpg         - showing the settings I used to generate the SDD_Wkr.pp files.

2. SDD_Wkr.asm          - assembler produced by our normal build process,
                                     automatic parser preprocessing. Project 1.

3. SDD_Wkr.asm          - assembler produced by our normal build process,
                                     automatic parser preprocessing. Project 2. 

4. SDD_Wkr-pp.asm    - assembler produced by building SDD_Wkr.pp renamed SDD_Wkr.c,
                                     manual parser preprocessing. Project 1.

5. SDD_Wkr-pp.asm    - assembler produced by building SDD_Wkr.pp renamed SDD_Wkr.c,
                                     manual parser preprocessing. Project 2.

Interestingly, the SDD_Wkr-pp.asm files are the same, barring file paths (comparison between projects is simplified by removing the string "Build_Experiment_Down_One_Folder_Level/" from project 2 files).

The odd one out is SDD_Wkr.asm for project one. Comparing this with the others suggests that it is getting built in a different order.

This is certainly a strange problem. So the assembly files created as part of your normal build process are different for the two builds. However, if you create preprocessed (.pp) files out of the two source files and then build them with the same options as used in your normal build process, then the assembly files generated are the same.

At this point, I can't explain why the .asm for build 1 is placing functions in a different order, when it is the exact same source and build options as build 2.

Are the SDD_Wkr.pp files generated within the two builds the same? Could you attach the SDD_Wkr.c and SDD_Wkr.pp files from the build 1 and build 2 directories as well? Not sure if it is going to lead anywhere but might be worth taking a look at.

The SDD_Wkr.pp files are identical apart from their dates.

I've compared SDD_Wkr.pp with SDD_Wkr.c and everything is as you would expect.

Phil Smith1 said:

The SDD_Wkr.pp files are identical apart from their dates.

I've compared SDD_Wkr.pp with SDD_Wkr.c and everything is as you would expect.

There is one more thing I can suggest to look at. Since the CCS build generates different SDD_Wkr.asm files for the two builds, could you put the projects back to their original settings (ie remove the preprocessing options you had added to create .pp files), and then compile only this one source file? You can do this by right-clicking on the .c file in the CCS Project Explorer view and choose "Build Selected File". This should regenerate the .asm files. Are these .asm files still the same from the previous full build and still different for the two builds?

If so, I'm not sure where to go from here. It is indeed a very strange issue and I'm at a loss as to what to suggest next.

Hi.

I tried your suggestion. Still different results - the same output as before.

Puzzling to say the least.

I have done a bit of investigation into this and found the following :-

Using TI CCS v5.5.0.00077
with a workspace at C:\Users\abcdef\workspace_v5_5 (on Win7)
And "C:/ti/ccsv5/tools/compiler/arm_5.1.1/bin/armcl"
And the attached full project

If I build the project using different length paths I get different addresses for method SC_AM_cancelPeriodicAlarm (along with others)

(From .map file GLOBAL SYMBOLS: SORTED ALPHABETICALLY BY Name )
Q:\Users\abcdef\Documents\Characters12345678                      = 00020000
Q:\Users\abcdef\Documents\Characters12345678901234                = 00020000
Q:\Users\abcdef\Documents\Characters123456789012345               = 00020060
Q:\Users\abcdef\Documents\Characters123456789012345678901234567   = 00020060
Q:\Users\abcdef\Documents\Characters1234567890123456789012345678  = 0002009c

This results in different output binaries as shown by objdiff

This behaviour is the same on Win7 SP1 64-bit and WinXP SP3 32-bit

david price2 said:

with a workspace at C:\Users\abcdef\workspace_v5_5 (on Win7)

In which directory does the project reside? Do you open a workspace at the above directory, then import the project?

david price2 said:

If I build the project using different length paths

Not sure I understand what you mean here. Which path are you adjusting? The location of your workspace? If you can elaborate on exactly what you did, I will try to see if I can reproduce the behavior.

I didn't touch the workspace let CCS deal with it(gave it incase it matters) but the path to the source was for example

Q:\Users\abcdef\Documents\Characters12345678901234\2014_03_26_1300_dp

Which was then Imported and built

Then I deleted the project in CCS, Closed CCS, changed the Characters... directory name, started CCS, re-imported, deleted the TargetHW folder and re-built.

Saving the .map and .out files after each build.

I did this for each of the Characters... directory names stated above.

Thank you for the details. I was able to reproduce the issue. It seems related to building within the c:\Users\username directory because if I place the source instead at c:\work or something other than the Users area, then I cannot reproduce the issue. Could you give that a try if you have a chance (copy the 2014_03_26_1300_dp contents to some other area within c:\ other than c:\Users)  and confirm that the issue does not appear?

In the meantime, I have filed a bug to have this looked at by the compiler team. The tracking # is SDSCM00049890 and you can track its status using the SDOWP link in my signature.

I used the following and got the same behaviour:-

Q:\Work\onchain\Documents\Characters12345678901234
Q:\Work\onchain\Documents\Characters123456789012345

However I didn't with :-

Q:\WorkingProjects\Docum\Characters12345678901234
Q:\WorkingProjects\Docum\Characters123456789012345

Despite there being the same amount of characters in the directories

But did with :-

Q:\WorkingProjects\Docum\Characters1234567890123456

So it must be a problem with the whole path INCLUDING directory seperators

np, having a reproducible test case is always handy.

Looks like that's fixed it, although one has to change the compiler in the projects properties under CCS General

Will there be a standalone download for the Arm Compiler Tools ?

We need to be able to reproduce the compiler environment in the future.

david price2 said:

Will there be a standalone download for the Arm Compiler Tools ?

There isn't one at this time. This may change in the future, but I can't say if or when it will.

Hi,

I'm in the process of tracking down a very similar issue when using the C2000 compiler (for the 28035) as supplied in the CCS v5.5.0.00077 release.  Not yet sure if it is me or the parser as it was determined in this thread.

Does this bug have a bearing on the C2000 compiler (6.2.0) as well?

If so, and if there is an update available how do I go about getting a formal compiler update to try and see if this resolves my issue?

Thanks,

Barney

Barney De Villiers said:

Does this bug have a bearing on the C2000 compiler (6.2.0) as well?

Yes this bug would affect C2000 compilers up till 6.2.4.

You can download an update by going to CCS menu Help->Check for Updates. Select the C2800 Compiler Tools (the latest version curently is 6.2.9) and proceed with the installation. You can then set your project to build with 6.2.9 from the Project Properties and see if it resolves your issue.

Hi,

Thanks, the C2000 compiler update from 6.2.0 to 6.2.9 solved my problem.

Out of interest, in my situation the problem was that the compiler was installed in two different locations. The source was in exactly the same folder name. One the one machine C:\ti\ccsv5 and the other D:\Programs\TI\ccsv55\ccsv5.

Thanks and kind regards,

Barney