|question on a "logical" cmp utility firstname.lastname@example.org (taek) (1998-09-18)|
|Re: question on a "logical" cmp utility email@example.com (Bruce Dawson) (1998-09-22)|
|Re: question on a "logical" cmp utility: a proposal firstname.lastname@example.org (1998-09-22)|
|Re: question on a "logical" cmp utility cliff.click@Eng.Sun.COM (Clifford Click) (1998-09-22)|
|Date:||18 Sep 1998 23:06:09 -0400|
|Organization:||Netscape Communications Corp.|
Hi, I'm hoping you guys are the experts on this.
> I'd like to know whether there is a tool out there which will do a
"logical" diff between two binary files.
> > My scenario:
> > I compile an object file object.o
> > I move the object file to object.o.save
> > I recompile the object file (same machine, same environment, same
> > I want to check that the resulting new object.o is the same as the
> > How can I do this? Unfortunately when I dump the file the hex
string for some of the symbols have changed, despite all other
variables held constant. Two differences that I see on Solaris 2.5.1 is
that a static process id is prepended to each variable; this
process id is unique and differs per compilation. Secondly, the offset
for the variables are occasionally off by a little bit. I've also
heard on NT that VC++ 4.2 and higher also embeds time and date stamps to
> > Goal:
> > I create a release of Project X from a nightly build (from
scratch). Call this Release.a
> > To keep things simple I delete the build and rebuild everything the
next night, with 1 bug fix (same location, same machines, etc.)
> > I want to generate a report (and a patch) that says libx.so is the
only file changed due to the 1 bug fix AUTOMATICALLY.
> > Problem: Currently all the tools I know, e.g. cmp, reports
EVERYTHING as different due to the different time stamps and other
object file differences.
> > So does anyone know of a tool which will accomplish my goal?
I think I may be able to write one but want to save myself the trouble
if possible. Especially if someone has written an efficient one.
I need to do this on HPUX, AIX, Solaris, IRIX, and NT so any solution
will be useful.
One comment I already received sheds additional light: "I once used
this technique to verify that about 1.5 million lines of code had not
been materially affected by automatic reindentation; I was quite
disappointed that comparison tools were not readily available.
Luckily, gcc 2.7 was pretty well-behaved about this for SunOS and
Solaris, so writing a tool to ignore the pro forma differences was
easy. I suspect that the amount of work involved will be very
compiler and platform specific, unfortunately.
The lack of such differencing tools is actually disturbing, or should
be to this newsgroup's audience. Differencing of object code for
meaningful changes should be an integral part of any compiler
development effort, in order to automate testing of the compiler
output during development and maintenance. Much more sophisticated
output analysis must go into devleopment, but for ongoing verification
efforts a differencer seems like a perfect solution.
However, I have never heard of a compiler vendor making a companion
differencing tool available to users who want to apply such standards
to their development environment. This implies to me that they don't
actually tend to have such tools, implying that they don't tend to
have the sort of QA I'd like to think they have. This sort of thing
makes spending money on compilers rather unpalatable, where
heavily-used alternatives exist.
To be fair, optimizing compilers go to a great deal of effort to
rewrite object code in different logically equivalent ways; that's
where all the glitter is in the compiler business. However, even an
optimzing compiler should output the same code when given identical
input; just being able to verify this would be a great step forward in
rigorously maintaining development environments. -Mark Carmichael" --
Taek Lee................................email: email@example.com
Netscape Communications Corp............(w) 650-937-2270
http://people.netscape.com/taek .......(f) 650-428-4330
Return to the
Search the comp.compilers archives again.