supporting deterministic 'ar'

[Chris Demetriou <cgd at google dot com>]

I'm occasionally bothered by the fact that 'ar' embeds the current
time and my uid/gid when building archives.  This is a real PITA if
you're trying to rebuild a bit-identical binaries to verify that (a)
you really didn't change anything unintentionally, and that (b) your
build tools don't have any unexpected external dependencies.  You
might want to do this if you're trying to build binary patches of
systems (including even .a files), or if you're extra-paranoid.


So, I've whacked together something quick that may do what I need.  In summary:

new flag 'D' to ar, which invokes deterministic mode.  In this mode,
timestamp of all incorporated archives is set to 0, as are uid/gid.
When creating an armap, the armap's timestamp is set to '999999999 '.
Since ar builds in armaps by default and since the timestamp way in
the future, if you're using this there's no reason to use ranlib
anymore -- and doing so would clobber the nice armap timestamp (unless
you used 'ranlib -t', in which case you'd get no change.

I've not yet tried to coerce GCC or other tools to support this, but
I've looked at GCC's build process enough (including build-to-build
diffs) to know what needs to be done I think.


the value '999999999 ' is a bit special.  The field where the
timestamp lives is 10 chars long (space padded), but at least in bfd
strtol is used to parse the ar_date field (in the wonderfully named
macro 'foo' in archive.c) so it really needs a space after it --
otherwise, old versions of binutils would choke on the value.

In archive.c, timestamp is kept in a 'long', and I rely on the fact
that 999999999 will either be converted to LONG_MAX by strtol (in
which case it will compare favorably to timestamps compared in
archive.c, which are cast to long), or if long is 64 bits it's the
largest value we can have right now.  In places where the code is
dealing with a 'long' variable in memory, I just use LONG_MAX instead.
 Could have used 0x7fffffff instead for all values, but given GNU ar's
use of strtol and the fact that times will only fit in signed 32-bit
numbers for so much longer, I figured using a larger number would be
better.


The attached patch is a WIP -- not nearly ready for submission yet (no
changelog, no docs, a few todos to be done).  What I'm hoping for is
feedback:

* Am I totally crazy to want to do this?

* Any negative consequences (of the idea or implementation strategy)
that anybody can think of?  (Obviously, 'ar u' becomes useless.)

* is there a better way to get LONG_MAX in archive.c?

* is this appropriate for a BFD flag, or a bit in the bitfield?  (it
seem closer to being a flag...)

* any preference about flag name?


thanks,

chris

Attachment: ar_deterministic.patch
Description: Binary data