Binary Comparison using objdiff.pl

I saw a case very similar to this one recently.  I'll tell you what we saw in that case.  You likely have the same issues.

The objdiff utility is comparing some sections that should not be compared.  One example is .strtab.  A bug has been opened against objdiff for this issue.

The ti.sdo.ipc.SharedRegion_0 section is not being handled properly in the linker and objdiff.  I filed ClearQuest entry SDSCM00038860.  You can track it with the SDOWP link in my sig below. 

The difference in the .const section is almost certainly a true difference.  In the other similar case, Codec Engine was being rebuilt each time.  And Codec Engine source code places a string in target memory with a time stamp of when it was built.  

There is nothing that can done at the tool level about the .const difference.  But for the other differences, tell objdiff to skip sections in the comparison.  Write a configuration file, and supply it on the command line with --config_file=file.  Yours would look like this:

    # Comments look like this
    SKIP_BY_NAME = .strtab
    SKIP_BY_NAME = ti.sdo.ipc.SharedRegion_0

Add other section names as needed.  In general, if sectti (another cg_xml script) doesn't show anything about the section, then you don't need to compare it.  You can read more about it in the cg_xml documentation.  There is a file named index.htm in the root directory of the cg_xml installation.  Load it into your favorite web browser.  Navigate to a address similar to: file:///C:/Program%20Files/Texas%20Instruments/cg_xml/docs/ofd/objdiff.htm#using_the_configuration_file_to_skip_sections .

Thanks and regards,

-George 

Thanks George, will follow the steps as told by you.

Regards,

Ravinder 

Hi George,

I have printed the verbose of .const difference between two binary files ( after skipping .strtab and ti.sdo.ipc.SharedRegion_0 sections ), it is something like this

======================================================================
Comparing Sections : section = .const
======================================================================
Raw data is different
   Byte 628726 is different
      vs2_m3video_whole_program_debug1.xem3: 0x31
      vs2_m3video_whole_program_debug2.xem3: 0x32
   Byte 628727 is different
      vs2_m3video_whole_program_debug1.xem3: 0x39
      vs2_m3video_whole_program_debug2.xem3: 0x30
  

My question is the byte offset which is printed onto console "628726" (0x997f6) for the difference encountered is correct ?

I compared it with Hex compare utility and found there are no difference at offset 0x 997F6, where as the timstamp difference is at "0xFCEE3" , the values of bytes which differ are correct.

Regards,
Ravinder

In ASCII, the two bytes 628726-7 are "19" in debug1, "20" in debug2.  Most likely this is a string representation of time, ultimately from using __TIME__ somewhere in the source code.

Hi,

I know its time representation, my question was why the byte offset shown using objdiff is not correct, i am assuming this offset is from the start of file.

Regards,

Ravinder 

The offset is probably the offset from the start of the section, which cannot be computed directly from the file position.

The byte offset reported by objdiff is from the start of the section.

-George

Hi George,

The above method of binary comparison works fine if we compare the binaries built on same PC. But if i compare the pre-build binaries which comes as part of release and rebuild binaries build at  my end, i am seeing difference in many sections. Same set of tools are used to build the release at my end and functionality is same.

Have attached difference and also the binaries which i have compared.

4454.PreBuild_Rebuild.txt

4375.Binaries.zip

Would like to know why the difference is coming when set of tools used are same.

Thanks and Regards,

Ravinder

There are a lot of small differences, ultimately coming from a string $C$SL41 at target address 0x8ff8a184 in .const.

In vs2_m3video.xem3, this string is:

'    package ti.sdo.ipc.family (D:/AVME4_Tools/ipc_1_22_00_13_eng/packages/ti/sdo/ipc/family/) [1, 0, 0, 0]'

In vs2_m3video_whole_program_debug.xem3, this string is:

'    package ti.sdo.ipc.family (F:/Tools/sdk_5008/ipc_1_22_00_13_eng/packages/ti/sdo/ipc/family/) [1, 0, 0, 0]'

There are few difference in other sections, can you let me know what is the reason behind them.

My idea of using this utility was to do Automation. We have to build a release under Linux and Windows. In total we get 8 rebuild binaries, goal  was to execute only pre-build binary and do binary comparison for rest using this utility. Let me know if there is any other utility available which can do this.

Thanks and Regards,

Ravinder

A lot of those differences are caused by the change in size of .const due to this string.  Because the size of .const has changed, the starting addresses of .data,  .stack, and .sysmem are moved, and so any pointer into any of those sections will change, which for ARM means the .text section will change.  Section "xdc.meta" is not allocated in target memory and should be ignored for binary comparison.

Archaeologist

In vs2_m3video.xem3, this string is:

'    package ti.sdo.ipc.family (D:/AVME4_Tools/ipc_1_22_00_13_eng/packages/ti/sdo/ipc/family/) [1, 0, 0, 0]'

In vs2_m3video_whole_program_debug.xem3, this string is:

'    package ti.sdo.ipc.family (F:/Tools/sdk_5008/ipc_1_22_00_13_eng/packages/ti/sdo/ipc/family/) [1, 0, 0, 0]'

This difference is likely b/c Codec Engine [by default] adds a full list of all packages and their original locations into the final executable.  The end user can emit this very valuable information via the popular CE_DEBUG feature, and it greatly helps with support as debug logs automatically provide details about what's in the system.

This particular feature can be disabled, a description for doing so is in this FAQ.  Please think twice before doing this, as the benefit of enabling this automation test may not outweigh the increase in support burden.

Chris

Hi,

In one of my early queries it was communicated that the utility doesn't work on relative address of section's. But it takes the start address for comparison from start of each section.

Does it mean i can't use this utility for binary comparison for binaries generated on different PC's with tools placed under different directories.

Regards,
Ravinder 

Ravinder Singh

Does it mean i can't use this utility for binary comparison for binaries generated on different PC's with tools placed under different directories.

That is a limitation at present, unless you remove the CE_DEBUG information as described by the FAQ referenced in the post from Chris.  We are considering solutions to this problem.  But any such solution will not be released for quite some time.

Thanks and regards,

-George