tags:

views:

28

answers:

1

Hello,

I am looking for a binary diff tool which allows me to mask parts of the binary files so they won't be taken into account.

The challenge I am facing is the following: Once we finished actively developing a branch of our embedded software we put it into maintenance. This means it is still build once a week to ensure that it doesn't erode and is not buildable any more. This is necessary so that once we urgently need to fix a bug or add a little feature we can concentrate on this and not need to solve other problems as well.

With our current approach we know that the branch still builds without errors but we do not know whether the produced binaries are is still the same. So I thought comparing a “golden master” binary against what was build and decide whether they are identical would be an approach to this. Anyhow, the files will never be identical to the bit because e.g. build dates are part of the binaries.

Does anyone have an idea or has even solved this puzzle before? I guess I am not the first developer facing this challenge.

Regards, Mark

A: 

The Linux from Scratch project ran into this problem when they were transitioning from Glibc 2.2 to Glibc 2.3, I think in 2001. They developed some scripts and techniques to reduce the amount of noise, but it was still only reducing the amount of noise. They still needed to manually inspect the remaining differences. Anyway, if you dig around the mailinglist archives from around 2001 to 2003, you should find some pointers.

However, aren't you going at this the wrong way? I mean, the interesting question is not so much whether it still builds identical binaries, but rather whether it still works, isn't it? So, it is much more interesting whether it still passes the testsuite rather than whether it is still the same binary.

After all, nobody cares whether it is still the same binary, if there is no obversable difference in behavior. And if it's broken, then nobody is going to take "Yes, I know, but it is broken exactly the same way it was last week, and I can prove it!" as an excuse.

Jörg W Mittag
I am intentionally going at it this way. The devices concerned do not have automated tests. Testing them manually costs a lot of time and resources. This is only done with release candidates. I want to ensure that my toolchain is still able to produce the very same executable it did when it produced the lastest release. Between releases there can be easily three years or so. Because I fear that the build machine or the operating system on it will erode over time I need some kind of test that it can still do what it once could.
Mark
So yes, I want to be able to prove that my binaries are still broken exactly the same way as they were three years ago.
Mark