Coldfire: identical project does not produce identical binary output

cancel
Showing results for 
Search instead for 
Did you mean: 

Coldfire: identical project does not produce identical binary output

2,209 Views
JoelWI
Contributor I
I have found that different developers produce different binary output from the same project with the same tools. I would like to know what other factors we need to control in order to reproduce the output on different workstations.

The CodeWarrior IDE Help->About list of installed products shows the same versions of all the same files. The project .mcp file and all source files are identical, checked out of version control into the same local pathname. I already found that an existing *_Data directory can affect the build, so our procedure is to delete that folder before opening and building the project. I believe that developers have the same standard libraries, but it should not matter because we are building library projects, which do not link in any external code.

For some projects, the different workstations do produce the same output, but for others, although the output files are the same size, the contents do not match. I suspect that both the contents are rearranged within object files and the order of the objects may be changed, but I do not have proper elf tools for this format, so I am guessing from looking at binary differences. The differences are not in path names, labels, or other text information.

Any ideas what else could cause the differences?

Message Edited by CrasyCat on 2007-04-13 10:54 AM

Labels (1)
0 Kudos
4 Replies

408 Views
CompilerGuru
NXP Employee
NXP Employee
Which tools do you use?
There maybe many reasons why the files would differ, for example the debug information can contain the modification time of input files, there can be other timestamps, the C __TIME__ macro, the search order for recursive directories is not specified and there are a lot of other possible causes too.
The thing to do is to compare text dumps of the files to understand what the difference means.
To dump the binaries, add them to a new project and then do a Disassemble in the context menu (enable all disassembly options first, maybe). For HC08/HC12 there is also a decoder.exe, call it with the options -e -ed -d to get as much text as possible.

Daniel
0 Kudos

408 Views
JoelWI
Contributor I
We are using CW for Coldfire.

File modification dates do not seem to affect the binary even with debug data included. When I touch a source file, or make a non-code change such as adding comments, the output is unaffected.

We do not happen to use __TIME__ in these projects, and differences are substantial, not just a few bytes here and there.

I was able to build GNU binutils for m68k-elf under Cygwin, but objdump has some problems with the CW Coldfire format. However, ar works and lists the objects in the same order in the library, so I think that much is the same. Some of the object files are the same, too. With readelf, and now with disassembly in CW, I see that the differences in a particular object file are the addends to .debug for most of the relocation entries in the .rela.debug sections.

What are "recursive directories" for which search order is undefined?
0 Kudos

408 Views
CompilerGuru
NXP Employee
NXP Employee
With recursive directories I meant the access paths which can be defined in the access paths tab.
If the little folder shows up in the second column of any access path, then all sub folders are searched too. And at least under Win98 some years ago, CW did use the native order of the directories on the disk, and this one could differ even if the folders were otherwise the same. I think XP always presents the files sorted, but not 100% sure.

Daniel
0 Kudos

408 Views
JoelWI
Contributor I
Thank you for that explanation. I had not considered it. We now tried turning off the recursive directory search for all the user search paths, and it did not affect the output, but we have not yet tried changing the recursive {Compiler} path into separate paths for the system search path.

It seems like the search order would only matter if there were multiple files with the same name. Is that correct? Otherwise the compiler should find the same file when it looks for a filename regardless of the search order. I could poke around a bit, but maybe you already know whether the compiler has various versions of header files lying around.
0 Kudos