CCS/TM4C129LNCZAD: Changing the directory name changed the binary file

Hello,

jkresse said:

I then did a test build, which worked, but the binary file does not match the previous binary file. Why, if none of the source files have changed, would the binary file change?

Are you looking at the executable *.out file, or an actual generated raw binary file?

Thanks

ki

Hi ki,

I'm looking at an actual generated raw binary file, produced by tiobj2bin from the .out file that was generated.

Ok. I would expect differences with the *.out file. The binaries, not so much.

Where the two binary files built on the same PC using the same versions of the tools (CCS, compiler, etc) with the only change being updates to some path information?

I agree, I wouldn't expect the binaries to differ, and was planning on using that as a check that I hadn't broken anything before making any actual source code changes.

And, yes, everything is being done on the same PC, the same tools, etc. The only change was to rename a subdirectory from, say "xxx" to "xxx_local", and update the project to use that new name. If I change that back, the binary again matches the original.

jkresse said:

The only change was to rename a subdirectory from, say "xxx" to "xxx_local", and update the project to use that new name.

same linking order (I had to specify the linking order)

Do you have the map or out files from the old project to compare against those from the new project?

A textual comparison of the map file can show if symbols have been re-ordered, which could be to a different link order.

CCS/CCSTUDIO: Bin files don't match has some suggestions about using objdiff to compare out files while ignoring the meta-data.

Matching a raw binary file produced by a previous build is possible, but difficult.  For a better sense of what is involved, please see this forum thread.

I don't know what causes the difference in this case.  To explore that, I recommend you use the utility objdiff from the cg_xml package to compare the executable .out files (not the raw binary files).  If you have trouble understanding the output of objdiff, please post it here.

Thanks and regards,

-George

Thanks, Chester! I will try using those tips.

George, thanks for that info! I'll check that out.

Hi George,

I had to work on a few other issues, but have now set up and am trying to use objdiff (it's an impressive toolset!).

I just tried performing a test of objdiff (under Win10, using objdiff.exe) and got the following error message:

$ objdiff.exe orig.xml test.xml

Processing orig.xml ...

Processing test.xml ...

Comparing files ...

Can't use an undefined value as a SCALAR reference at script/objdiff.pl line 1663.

I'll take a look at the script to see if I can figure it out on my own, but thought I'd check to see if it was a known issue, etc.

Thanks in advance!

Jim

I have not seen that problem with objdiff.  I don't know what causes it.

Please show the armofd command you use to create the XML files.

Thanks and regards,

-George

There was no armofd contained in the package at the link you mentioned, only ofd6x.

This is one of the commands I used:

$ ofd6x.exe -x -o=test.xml NSC_BUILD_DIR.out

The .xml files appeared to work ok with sectti.

Instead of ofd6x, please try armofd instead.  Get it from the latest version of the TI ARM compiler you have.  It is found in the \bin directory of the compiler installation, along with all the compiler executables.

Thanks and regards,

-George

I found and used armofd from the \bin directory of the compiler (version 5.2.9) to generate the .xml files again. I got the same error message as before when using objdiff.

Then I need to reproduce the problem.  I'd appreciate if you would put the two .out files in zip file, and attach that to your next post.  Or, if you don't feel comfortable with that, the two XML files instead.  

Thanks and regards,

-George

I thought that might be the case; not surprised.

Let me see what I can do. If I exclude rawdata, I may be able to send the XML files. Let me see if I can generate those and find out if they have the same error.

Ok, once I excluded raw_data from the XML files, objdiff works.

armofd claimed norawdata was the default, but I could see raw_data in the XML files, and once I explicitly used --obj_display=norawdata, those sections were gone.

I'll try more examples tomorrow and let you know how it goes.

I'm glad you found a workaround.

The question at the start of this thread is about why changing the name of directory caused the .out file to change.  Where do things stand on that question?

Regarding the problem with objdiff ... Based on what I see so far, I suspect a problem with one of two things: how the OFD utility puts the raw data in the XML, or how objdiff gets the raw data from the XML.  I'd appreciate if I could investigate what happened.  I understand you don't want to post the .out files in a public forum.  Please consider sending them just to me by private message.  Hover your mouse over my name or avatar. A box will pop up. Click on Send a private message. In the message compose interface which comes up, use the paper clip icon to attach the zip file which contains the two .out files.

Thanks and regards,

-George