• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 53 subscribers
  • Views 901 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Builds from two different workspaces of projects having same files do not produce identical hex files.

John Osen
Genius 3585 points

I am using CCS 5.5 on a variety of Tiva chips.  I output .out files for debug and .hex files for the factory.  The last step of development is to:

  1. commit and tag all projects to SVN (from the dev area)
  2. export them to a new empty directory (the export area)
  3. create a new workspace
  4. import the four projects
  5. rebuild
  6. compare the hex files in the dev and export areas

If the hex files compare, then there is reasonable assurance that a engineer recovering the development package months or years down the road, using the same compiler package, will be able to generate the exact same hex file.

The problem is the hex files do not compare - for one of four targets, each using four CCS projects (one app and three libraries).  The differences are significant.  Looking at the resulting map files, it appears that the size of many modules change, as if optimization levels are different.

I run a directory comparison between the dev and export areas and all *.c, *.h, .project, .cproject, .ccsproject prove to be identical.  The three projects having library outputs end up with libraries where the library table of contents from armar have all obj files of different sizes.

I save the output from the CCS build's Console window into text files and compare the two builds, except for the root of the file locations, all compare identically, i.e. the options are the same, the compiler path is the same, the optimization is the same, ...

I copy the files from the export to the dev area and rebuild and get what was built in the dev area.   So the changes seem to be locked to the CCS workspace.  But I have started from a new workspace on both sides repeatedly.

I have found one difference in 'makefile' where the line:

CommonLib.lib: $(OBJS) $(LIB_SRCS)

would contain $(OBJ_SRCS) where this is defined as:

OBJ_SRCS :=

So I do not think the difference is a player, but why would CCS add it in one makefile and not the other?

For three targets, the hex files compare exactly.

So how can I have identical source and project files, use the same compiler and get a different hex file?

  • 0
    Guru 92251 points

    John Osen said:
    So how can I have identical source and project files, use the same compiler and get a different hex file?

    What version of the TI ARM compiler are you using?

    You may have encountered the problem in Inconsistent Build Output

  • 0 in reply to Chester Gillon
    Genius 3585 points

    Chester,

    Chester Gillon said:
    What version of the TI ARM compiler are you using?

    5.1.2 and so close to release I am 100% resolved not to update the tool chain until after release.  It would invalidate all of our testing.

    Thanks for the response and the link.  I will include two files identifying additional info:

    1. I went to the map file and found in which module the maps started to diverge
    2. I went into that module and poked around and found nothing of interest
    3. I then caused each workspace's project to product listing files for that module
    4. I then compared the listing files and looked carefully at what was happening.
    5. It appears that at some point the compiler decided to inline a static function in one compilation and create an actual function section in the other.

    This is completely consistent with your link.  If I read the link correctly, it says "depending on the module's path (possibly path length), an internal compiler variable gets stomped on and turns on inlining unintentionally and the problem was fixed on something like 5.3."

    About 20 hours working this issue.  As committing and exporting from SVN was involve, it was a likely bet I had messed that up.

    It is a much better way to end the day knowing I can move on...

    Fullscreen 1452.DevArea.txt Download 
    Export area

Search .lst files for PushOntoTxCircularBuffer
WRLS.lst (26 matches)
3,691: 3380 00000000                   .sect   ".text:PushOntoTxCircularBuffer"  
3,693: 3382                            .thumbfunc PushOntoTxCircularBuffer  
3,696: 3385                    $C$DW$240       .dwtag  DW_TAG_subprogram, DW_AT_name("PushOntoTxCircularBuffer")  
3,697: 3386                            .dwattr $C$DW$240, DW_AT_low_pc(PushOntoTxCircularBuffer)  
3,699: 3388                            .dwattr $C$DW$240, DW_AT_TI_symbol_name("PushOntoTxCircularBuffer")  
3,709: 3398                            .dwfde $C$DW$CIE, PushOntoTxCircularBuffer  
3,716: 3405                    ;* FUNCTION NAME: PushOntoTxCircularBuffer                                   *  
3,731: 3415                    PushOntoTxCircularBuffer:  
3,740: 3424                    ; 682 | static void PushOntoTxCircularBuffer( WRLS_msg * msg ) {                 
13,226: 12120                    ; 2124 |     PushOntoTxCircularBuffer(msg);                                       
13,292: 12181                    ; 2134 |     PushOntoTxCircularBuffer(msg);                                       
13,308: 12197                    ; 2138 |     PushOntoTxCircularBuffer(msg);                                       
13,334: 12218                    ; 2142 | PushOntoTxCircularBuffer(msg);                                           
13,339: 12223                            .dwattr $C$DW$690, DW_AT_name("PushOntoTxCircularBuffer")  
13,341: 12225 00000050 FFFEF7FF!         BL        PushOntoTxCircularBuffer ; [DPU_3_PIPE] |2142|  ; [KEEP 32-BIT INS]  
13,342: 12226                            ; CALL OCCURS {PushOntoTxCircularBuffer }  ; [] |2142|   
13,354: 12238                            .dwattr $C$DW$691, DW_AT_name("PushOntoTxCircularBuffer")  
13,356: 12240 0000005c FFFEF7FF!         BL        PushOntoTxCircularBuffer ; [DPU_3_PIPE] |2138|  ; [KEEP 32-BIT INS]  
13,357: 12241                            ; CALL OCCURS {PushOntoTxCircularBuffer }  ; [] |2138|   
13,370: 12254                            .dwattr $C$DW$692, DW_AT_name("PushOntoTxCircularBuffer")  
13,372: 12256 00000068 FFFEF7FF!         BL        PushOntoTxCircularBuffer ; [DPU_3_PIPE] |2134|  ; [KEEP 32-BIT INS]  
13,373: 12257                            ; CALL OCCURS {PushOntoTxCircularBuffer }  ; [] |2134|   
13,408: 12287                            .dwattr $C$DW$694, DW_AT_name("PushOntoTxCircularBuffer")  
13,410: 12289 00000080 FFFEF7FF!         BL        PushOntoTxCircularBuffer ; [DPU_3_PIPE] |2124|  ; [KEEP 32-BIT INS]  
13,411: 12290                            ; CALL OCCURS {PushOntoTxCircularBuffer }  ; [] |2124|   
15,535: 14234 0000001c                   .sect   ".text:PushOntoTxCircularBuffer"  

"C:\\ti\\ccsv5\\utils\\bin\\gmake"
-k WRLS.obj 
'Building file: C:/Data/Code/LM4FCommon/CommonLib/trunk/WRLS.c'
'Invoking: ARM Compiler'
"C:/ti/ccsv5/tools/compiler/arm_5.1.2/bin/armcl"
-mv7M4
--code_state=16
--float_support=FPv4SPD16
--abi=eabi
-me
-O1
--opt_for_speed=0
--include_path="C:/ti/ccsv5/tools/compiler/arm_5.1.2/include"
--include_path="C:/ti/TivaWare_C_Series"
-g
--gcc
--define=css
--define=MONITOR
--define=WRLS_CAN
--define=MRF24J40
--define=PART_TM4C123GH6PGE
--define=TARGET_IS_BLIZZARD_RA1
--diag_warning=225
--display_error_number
--gen_func_subsections=on
--c_src_interlist
--asm_listing
--preproc_with_compile
--preproc_dependency="WRLS.pp"  "C:/Data/Code/LM4FCommon/CommonLib/trunk/WRLS.c"
'Finished building: C:/Data/Code/LM4FCommon/CommonLib/trunk/WRLS.c'
    Fullscreen 1106.ExportArea.txt Download 
    Export area

Search .lst files for 
WRLS.lst (4 matches)
13,129: 12033                    ; 2124 |     PushOntoTxCircularBuffer(msg);                                       
13,199: 12098                    ; 2134 |     PushOntoTxCircularBuffer(msg);                                       
13,220: 12114                    ; 2138 |     PushOntoTxCircularBuffer(msg);                                       
13,236: 12130                    ; 2142 | PushOntoTxCircularBuffer(msg);                                           

"C:\\ti\\ccsv5\\utils\\bin\\gmake"
-k WRLS.obj 
'Building file: C:/Data/Export/LM4FCommon/CommonLib/trunk/WRLS.c'
'Invoking: ARM Compiler'
"C:/ti/ccsv5/tools/compiler/arm_5.1.2/bin/armcl"
-mv7M4
--code_state=16 
--float_support=FPv4SPD16
--abi=eabi
-me
-O1
--opt_for_speed=0 
--include_path="C:/ti/ccsv5/tools/compiler/arm_5.1.2/include"
--include_path="C:/ti/TivaWare_C_Series" 
-g
--gcc
--define=css
--define=MONITOR
--define=WRLS_CAN
--define=MRF24J40
--define=PART_TM4C123GH6PGE
--define=TARGET_IS_BLIZZARD_RA1
--diag_warning=225
--display_error_number
--gen_func_subsections=on
--c_src_interlist
--asm_listing
--preproc_with_compile
--preproc_dependency="WRLS.pp"  "C:/Data/Export/LM4FCommon/CommonLib/trunk/WRLS.c"
'Finished building: C:/Data/Export/LM4FCommon/CommonLib/trunk/WRLS.c'

  • 0 in reply to John Osen
    TI__Guru**** 173310 points

    John,

    Chester is correct. This does sound very much like the bug in the referenced thread, which is fixed in compiler release 5.1.3 and higher. I understand that you may currently not be in a position to update, but when you are, the updates are available through the CCS update site.