Binary File Differences: When Do Differences Matter?

We will soon be building our software system on new hardware (same make/model, 
just new boxes).  I have noticed that even on our existing hardware, building 
the exact same software from the same source will give differing binary files, 
some even with minor file size differences.  So now, when we move over to the 
new hardware, how can we be sure that we are still building the same software 
given that the binaries contain differences even without changing systems?  Of 
course, we will be completely testing the software built on the new system.  Is 
there any way to tell if the differences in the binary files are differences 
that will affect the actual operation of the software, or perhaps the ability to 
update a single dynamic library?  I'd like to be able to do some kind of 
checkout other than the full system test to give me some confidence that the new 
hardware is building the same system as the old hardware.  Any suggestions?

In article <xPNFf.1$ XXXX@XXXXX.COM >, Robert Halonen



If sources and makefiles hasn't changed, then it's probably compiler
changes -- usually bugfixes or better optimized code generation.


You could disassemble the binaries and compare to identify differences.

Since you say it's a slight change in file size, the differences are
most likely not that large, and can be read by hand once the diff'd
sections has been identified.

You can also use /usr/ccs/bin/elfdump to compare the functions
enumerated in both sets of binaries. I'm not sure there's a Solaris
utility like GNU's objdump (part of their binutils tools).

(As of Solaris 9/SPARC, elfdump was in the SUNWbtool package.)

With GNU's objdump, if you build the binaries with -g, then you can use
objdump -d -S to show both an assembly language disassembly along with
references to the corresponding source code lines.

E.g., on Linux with GNU binutils installed:

$ vi hello.c

#include <stdio.h>

int main()
{
	int foo=0;

	printf("Hello, world!\n");
	foo=5;
}

$ gcc hello.c -g -o hello
$ objdump -d -S hello
[...]
08048384 <main>:
#include <stdio.h>

int main()
{
 8048384:       55                      push   %ebp
 8048385:       89 e5                   mov    %esp,%ebp
 8048387:       83 ec 08                sub    $0x8,%esp
 804838a:       83 e4 f0                and    $0xfffffff0,%esp
 804838d:       b8 00 00 00 00          mov    $0x0,%eax
 8048392:       29 c4                   sub    %eax,%esp
        int foo=0;
 8048394:       c7 45 fc 00 00 00 00    movl   $0x0,0xfffffffc(%ebp)

        printf("Hello, world!\n");
 804839b:       c7 04 24 a4 84 04 08    movl   $0x80484a4,(%esp)
 80483a2:       e8 01 ff ff ff          call   80482a8 <printf@plt>
        foo=5;
 80483a7:       c7 45 fc 05 00 00 00    movl   $0x5,0xfffffffc(%ebp)
}
 80483ae:       c9                      leave  
 80483af:       c3                      ret    
[...]

I am not sure what the Solaris equivalent to objdump -d -S might be, but
mentioned the GNU version here so that someone may be able to offer the
Solaris equivalent.

-Dan

Actually it's trickier than that. I'm currently struggling with the same 
issue as the OP. I've always thought that Solaris ELF binaries were 
"stable" - i.e. that a file compiled on the same machine twice with the 
same cmdline and environment a few minutes apart would generate 
identical bits each time. But from a test, this seems to be true when 
compilation and linking is done via the gcc toolchain but *not* with Sun 
Studio 11.

I just tracked this a little further. Turns out gcc generates nonvarying 
binaries with or without the -g flag whereas Sun Studio ("cc") generates 
identical output without -g, but when -g is turned on the checksum 
changes from build to build. See below:

% cc -o hello hello.c && cksum hello
123815386       6888    hello
% cc -o hello hello.c && cksum hello
123815386       6888    hello

% cc -g -o hello hello.c && cksum hello
3486775769      7556    hello
% cc -g -o hello hello.c && cksum hello
1243289241      7556    hello

Can anyone tell us the answer? Does Sun Studio insert a date stamp into 
the debug data or what? And is there a way to suppress that?


Presumably one could also just compile the GNU objdump for Solaris. Or 
copy the executable to a Linux machine and objdump it there. ELF is ELF.

HT

For starters, you must strip the binaries.

See 
80040 When I Recompile my Code, I do not get Identical Object Files.
    http://www.**--****.com/ 
for further details.


Thomas

On 7/2/06 4:37, in article  XXXX@XXXXX.COM , "Henry






Sun includes elfdump and dump in the SUNWbtool package, which do a good job
of analyzing ELF files.

Cheers,

Chris

This probably is due to the globalization prefix. 
No documented and supported way to suppress that. 
An undocumented and unsupported -W0,-noglobal will prevent this 
but doing so will break dbx's break-and-continue (for -g case) and -xipo.


There's no exact equivalence, 
though er_src (part of Performance Analyzer in Studio) can do objdump -S
but most of other objdump functionality can be found in elfdump.
-- 
#pragma ident "Seongbae Park, compiler,  http://www.**--****.com/ "

Thanks! May be useful for the bag-of-tricks even if not supported.


I assume you mean edit-and-continue? I can (and do) live without that, 
but being unable to continue after a break would be quite troublesome :-)

HT

Ah, sorry. I meant fix-and-continue. 
-- 
#pragma ident "Seongbae Park, compiler,  http://www.**--****.com/ "

Thank you; that is very useful!  One question that is not explicitly stated:  Is 
it true that he strip command does not alter the actual execution of the library 
or executable; i.e. it does not affect the functionality?

That is true.

Ceri
-- 
That must be wonderful!  I don't understand it at all.
                                                  -- Moliere

When I do the strip and compare on object files and executables, the diff will 
come back identical.  Executable files still show differences though.  Any 
reasons why?

You haven't made your situation clear. In the first sentence you say 
that stripped executables show no differences. In the second sentence 
you say the opposite. Which thing did you mean? Are you saying that 
*stripped* executables or *unstripped* executables show differences?

HT

Oops, I meant "object files and shared libraries."  Sorry for not 
proofreading before posting.

I was able to reproduce this but the -W0,-noglobal flag suggested by 
Seongbae solves it. Remember that this is undocumented and unsupported.

HT

Thanks Henry.  Unfortunately we can't re-build our existing executables
with those options; perhaps doing a parallel build as a proof will be
sufficient.