RE: why would two copies of gcc-2.95.2 yield different output?

RE: why would two copies of gcc-2.95.2 yield different output?

[Rupert Wood]

Fergus Henderson wrote:

> > Is there perhaps a way for a mere mortal to reverse-engineer the
> > binaries and see what the differences are?
> 
> Use objdump (from the GNU binutils package).

It may be easier to use the two compilers to generate assembly output
for a few simple examples and diff those instead; if the assembly code
is all the same, then the difference is in the assemble or link steps or
there's a difference in libraries used. You may also get some clues by
diffing the specs files (found under
<prefix>/lib/gcc-lib/<machine>/2.95.2/specs) of the two compilers.

In any case, does it matter that the new compiler generates different
binaries? It depends how seriously you take your binary validation: even
if you rebuild the source to a tested binary with a one-line fix, it
could be argued you should re-run all your tests on the new binary. In
that case, you can just ship the binary you've got, bin the old compiler
and start using the new compiler for all future releases. (Or even jump
to a newer GCC version - if you want to stick with 2.95.x then there's
always 2.95.3, CVS gcc-2_95-branch or vendor, e.g. Debian, patches of
the CVS; or prehaps you could try GCC 3.1+.) In the worst case, you just
have to keep the old build environment until your tested binaries reach
end-of-supported-life: there's no reason you can't start using a new one
for new builds.

Rup.

Re: why would two copies of gcc-2.95.2 yield different output?

[David T-G]

[-- Attachment #1: Type: text/plain, Size: 3305 bytes --]

Rupert, et al --

...and then Rupert Wood said...
% 
% Fergus Henderson wrote:
% 
% > > Is there perhaps a way for a mere mortal to reverse-engineer the
% > > binaries and see what the differences are?
% > 
% > Use objdump (from the GNU binutils package).
% 
% It may be easier to use the two compilers to generate assembly output
% for a few simple examples and diff those instead; if the assembly code

That also sounds like a good approach.  Um, can you tell me how to do
that? :-)


% is all the same, then the difference is in the assemble or link steps or
% there's a difference in libraries used. You may also get some clues by
% diffing the specs files (found under
% <prefix>/lib/gcc-lib/<machine>/2.95.2/specs) of the two compilers.

Ah; OK.


% 
% In any case, does it matter that the new compiler generates different
% binaries? It depends how seriously you take your binary validation: even

They take it pretty seriously, in fact; this is a DoD contractor.


% if you rebuild the source to a tested binary with a one-line fix, it
% could be argued you should re-run all your tests on the new binary. In

You're absolutely right, but I think that their software validation
process is robust enough that they take a look at minor changes like that
and carefully analyze how they will affect other parts of the system.
[Note that I don't claim that it *really* is, nor do I claim that such
testing is sufficient; the lack of other process control surrounding this
mess, which has brought me here in the first place, leads me to believe
that maybe those claims would be doomed to failure :-)  My only function
is to enable them to pin down their development environment so that when
they come back five years later to do some maintenance, as has prompted
this whole mess, they know what tools they used.  When they first tried
to dust off the old code it wouldn't even compile!]


% that case, you can just ship the binary you've got, bin the old compiler
% and start using the new compiler for all future releases. (Or even jump

I think we'll have to stick with that, but since the old environment is
here (not destroyed or decommissioned) that's not so bad.  If the best we
can do is improve things for projects starting tomorrow, we've still
taken quite a step.


% to a newer GCC version - if you want to stick with 2.95.x then there's
% always 2.95.3, CVS gcc-2_95-branch or vendor, e.g. Debian, patches of
% the CVS; or prehaps you could try GCC 3.1+.) In the worst case, you just

Agreed.


% have to keep the old build environment until your tested binaries reach
% end-of-supported-life: there's no reason you can't start using a new one
% for new builds.

Also agreed, and probably what we'll do.  Along the way we'll freeze the
entire development environment so that people quite updating the programs
in there and changing things out from under themselves!


% 
% Rup.


Thanks a *bunch* to all for their responses! & HAND

:-D
-- 
David T-G                      * It's easier to fight for one's principles
(play) davidtg@justpickone.org * than to live up to them. -- fortune cookie
(work) davidtgwork@justpickone.org
http://www.justpickone.org/davidtg/    Shpx gur Pbzzhavpngvbaf Qrprapl Npg!


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: why would two copies of gcc-2.95.2 yield different output?

[David T-G]

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

Fergus, et al --

...and then Fergus Henderson said...
% 
% On 12-Jun-2002, David T-G <davidtg@justpickone.org> wrote:
% > Is there perhaps a way for a mere mortal to reverse-engineer the binaries
% > and see what the differences are?
% 
% Use objdump (from the GNU binutils package).

That sounds interesting, but I have no idea how to do it :-)  Time to go
off and read another man page; thanks.


% 
% -- 
% Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
% The University of Melbourne         |  of excellence is a lethal habit"
% WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.


HAND

:-D
-- 
David T-G                      * It's easier to fight for one's principles
(play) davidtg@justpickone.org * than to live up to them. -- fortune cookie
(work) davidtgwork@justpickone.org
http://www.justpickone.org/davidtg/    Shpx gur Pbzzhavpngvbaf Qrprapl Npg!


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: why would two copies of gcc-2.95.2 yield different output?

[Fergus Henderson]

On 12-Jun-2002, David T-G <davidtg@justpickone.org> wrote:
> Is there perhaps a way for a mere mortal to reverse-engineer the binaries
> and see what the differences are?

Use objdump (from the GNU binutils package).

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

why would two copies of gcc-2.95.2 yield different output?

[David T-G]

[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]

Hi, all --

We have an existing build of gcc 2.95.2 in an environment that is a real
mess, so we're rebuilding the tools in an orderly fashion so that we can
shove the old junk off of a cliff.  I was surprised to find, though, that
for even the simplest "hello, world" programs the generated files were
different between our old and new copies.

Unfortunately, I don't know how the old one was built; it was taken from
the Edition 13 CDs of 1999 and built (I have to think that it was
compiled locally; it's in a unique path instead of /usr/local).  I
downloaded 2.95.2 from the web when I grabbed 3.0.4 and built it as

  ../$APP-$VER/configure \
    --prefix=$BASE \
    --exec-prefix=$BASE/$MYOS/$MYMAJ/$MYMIN/$MYCHIP \
    --enable-shared \
    --with-gnu-as \
    --with-gnu-ld \

which seem incongruous enough but could be the clue.

Is there perhaps a way for a mere mortal to reverse-engineer the binaries
and see what the differences are?  This wouldn't be of particular
interest, since they certainly work, except that changing the compiled
results means regression testing our entire product to ensure that it
still works as it's been signed off and thus means a *lot* more work.

Finally, I'm terribly sorry to be so rude but I really have only this
one question about gcc and so I'm not subscribed to the mailing lists.
Please be sure to copy me on your replies.  If you'd like to send them
all to me, I'll be happy to summarize my findings when the ideas quit
flowing in.


TIA & HAND

:-D
-- 
David T-G                      * It's easier to fight for one's principles
(play) davidtg@justpickone.org * than to live up to them. -- fortune cookie
(work) davidtgwork@justpickone.org
http://www.justpickone.org/davidtg/    Shpx gur Pbzzhavpngvbaf Qrprapl Npg!


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]