Binaries built on different machines do not match

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A co-worker of mine recently installed WinAVR so that he could compile a group of projects I'm working on. However, when he tries building the projects, one of the binaries does not match.

We are using the same source and makefiles (they were checked out directly from a repository), the same version of WinAVR (20070122), and we have the same version of make (3.80).

The other binaries in the project all match. The one that does not match is for an ATMega128, while the other binaries are for smaller ATMegas. Could far addressing have something to do with it?

We diffed the .map files and found that all the differences are in the .debug_str section. The elements in the section are the same, but the addresses for the elements in the section are slightly different. Here is a clip:

Mine:

.debug_str      0x00000000     0xc5f7
 *(.debug_str)
 .debug_str     0x00000000      0x181 eeprom.o
                                0x1fe (size before relaxing)
 .debug_str     0x00000181      0x82e gui_functions.o
                                0x9d1 (size before relaxing)
 .debug_str     0x000009af       0x36 gcc_utils.o
                                 0xea (size before relaxing)
 .debug_str     0x000009e5     0x73b3 main.o
                               0x76c2 (size before relaxing)
 .debug_str     0x00007d98       0xa1 keyboard.o
                                0x1f2 (size before relaxing)
 .debug_str     0x00007e39      0x25e lcd.o
                                0x44d (size before relaxing)
 .debug_str     0x00008097      0x15b led.o

His:

.debug_str      0x00000000     0xc5eb
 *(.debug_str)
 .debug_str     0x00000000      0x17b eeprom.o
                                0x1f8 (size before relaxing)
 .debug_str     0x0000017b      0x82e gui_functions.o
                                0x9cb (size before relaxing)
 .debug_str     0x000009a9       0x36 gcc_utils.o
                                 0xe4 (size before relaxing)
 .debug_str     0x000009df     0x73b3 main.o
                               0x76bc (size before relaxing)
 .debug_str     0x00007d92       0xa1 keyboard.o
                                0x1ec (size before relaxing)
 .debug_str     0x00007e33      0x25e lcd.o
                                0x447 (size before relaxing)
 .debug_str     0x00008091      0x15b led.o

The only other difference I can think of is that he is using Windows XP while I'm using Windows 2000.

I searched for documentation on the .debug_str section but I was unable to find any.

Any help is greatly appreciated.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does the .debug_str section really end up in hex or bin files, or just elf files? If hex and bin files are identical, does it matter if elf file isn't?

- Jani

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The hex files are different too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some ideas:

Use a checksum program (eg MD5) to check that all source files are identical on both machines.

Check so that no environment variables that affect the build is different.

Are the build trees placed in identical trees, at identical places? (Eg. What if debug info contains a path to a file and on one machine this path is much longer than on the other?)

Double check that there is one and olny one avr-gcc installation on each machine.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are probably differences in the file names, not the names, the path. Extended debug info holds the absolute path to the file name, so if you two have the sources in different directories the binaries (well, the debug information) will be different.

Use strings or diff in binary mode to see what is actually different (I'm sure Windows has something equivalent).

Have Fun,
Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to note that you are in dangerous teritory using 20070122, it was superseded by 20070525 for a good reason.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Some ideas:

Use a checksum program (eg MD5) to check that all source files are identical on both machines.

Check so that no environment variables that affect the build is different.

Are the build trees placed in identical trees, at identical places? (Eg. What if debug info contains a path to a file and on one machine this path is much longer than on the other?)

Double check that there is one and olny one avr-gcc installation on each machine.

I agree with Johan here. Please do some more checking along these lines.

The .debug* sections are used for, obviously, debug information. This information stays only in the ELF and does not go into the Intel Hex file.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Some ideas:

Use a checksum program (eg MD5) to check that all source files are identical on both machines.

Check so that no environment variables that affect the build is different.

Are the build trees placed in identical trees, at identical places? (Eg. What if debug info contains a path to a file and on one machine this path is much longer than on the other?)

Double check that there is one and olny one avr-gcc installation on each machine.

We used SVN and verified that both of us have the same version checked out and that no un-committed files exist.

The file trees are the same but they are in different locations, but would this really affect the hex file??

We did a full search through both of our PCs and we each only have 1 avr-gcc.exe.

I have isolated where the two hex files are different. It's in the range from 0x8940 to 0x8B60 (byte addresses). In the map file, it doesn't seem to match directly up with anything:

 .text.writeStrings
                0x000088ec      0x2aa lcd.o
                0x000088ec                writeStrings
 .text.headers  0x00008b96      0x1b4 lcd.o
                0x00008b96                headers

I'm starting to think that the debug differences in the map file are a result of whatever is causing the hex file difference, not the cause.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Redox wrote:

I'm starting to think that the debug differences in the map file are a result of whatever is causing the hex file difference, not the cause.

I repeat:
The .debug* sections are used for, obviously, debug information. This information stays only in the ELF and does not go into the Intel Hex file.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

maybe you are beyond this already, but get something like this if you don't have one already-
http://winmerge.org/

run it on the 2 lss files, you will see what/where they are different

I use it to figure out 'what just happened?'.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Disable debug mode and see if the hex files differ.

Use a disassembler to identify the nature of the difference. Post the hex files if you can and someone might figure it out.

C: i = "told you so";

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did a diff on the two listing files and I still cannot explain the difference. The part of the code that is different (it's only 1 part of 1 file in a 50+ file project) is not unique in any way that I can see.

I think we're going to take clawson's advice and upgrade to the latest version of WinAVR. Neither of our binaries will match what is in the repository now, but hopefully we will at least be able to build binaries that match each other (and function correctly of course!). For now, though, we'll just have to do all of the building on my machine.

Thanks everyone for your help.