Introduction

In order to reduce system test cycle it is required to compare the pre-build binaries ( which are part of release package ) with the re-build binaries ( gets generated when system test team rebuilds the package)”. These two binaries needs to be same (or almost same). This binary comparison is also useful in various other situation like debug the issues that might occur when customer tries to rebuild the release package.

We also noticed that certain sections or certain portions of executable are different even if both were built using same set of tools, components & release packages. This differences does not cause for any mismatch in the behavior.

This app note documents the list of procedures to follow in comparing two binaries generated by the TI CGT tool, so as to ensure both the binaries are functionally same.

Tools used for comparison

Any of the below utility can be used to compare the two executable, depending on the situation. This document describes when to use which utility.

fc - DOS utility to compare two plain binaris

diff - Linux utility to compare two plain binaries

objdiff - Utility to compare section by section of TI CGT generated binaries.
 This utility is part of the product "Code_Generation_Tools_XML_Processing_Scripts", & this can be downloaded from below link 
  "http://processors.wiki.ti.com/index.php/Code_Generation_Tools_XML_Processing_Scripts"

Compare binaries generated on same machine

Ensure that all the dependent components are in the same path:
- The debug section is being embedded with the path of all the files being used in the build, If the build path is differnt then this portion of the binary would show as the different. You can use objdiff tool to selectively ignore this section for comparison purpose. You can also use strip470 tool to remove the debug symbol before subjecting the executable for comparison.
- The strtab section is being embedded with the component paths by Codec engine, So if the build path is differnt then this portion of the binary would show as the differnce. To workaround this you can use "osal.Global.embedBuildInfo = false;” configuration while building so that the paths are not embedded in the target binary. You can also use objdiff tool to selectively ignore this section for comparison purpose.

Note: While using the objdiff tool the sizes of the section must not differ, other wise it reads all other subsequent sections also different. Read documentation of this for more info. So it is safe to ensure that dependent paths are same for build.

If the same path is ensured on each build then fc of diff tool can be used for comparison purpose.

Ignore the 20 byte differences account for usage of __DATE__ & __TIME__ macro in the code:
- Codec Engine is using __DATE__ && __TIME__ macros, this is being stored in the .const section of the executable. This accounts for max of 20 bytes
- Choose to ignore this differences, or ensure that Codec Engine is not getting rebuilt every time.

Compare binaries generated on different machines

Follow all the items mentioned in above section.
Ensure that tools path are same in both machines (ex: c:\ti_tools)
- This is for the same reason mentioned in "Compare binaries generated on same machine".

For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article Binary comparison of executables generated by TI CGT tools to reduce test cycle time here.