[PATCH] llvm-cov: Updated file checksum to be timestamp.
yuchenericwu at hotmail.com
Fri Nov 15 16:58:33 PST 2013
>> 2. Using the output file itself to seed hash function, which makes it
>> deterministic. I've tried implementing this using the size of the
>> output buffer and it was pretty simple. The problem with it, however,
>> is that there's a lot more chance for a change to the GCNO file to go
>> unnoticed. I also think that even if the source hadn't changed between
>> compiles, the new binary files shouldn't be compatible with the old.
> This is obviously the correct approach. In general, it's important to
> be able to have reproducible builds so that we can reproduce the same
> binaries from source, builds where outputs can be cached (for instance
> by modern non-make build systems that use the md5 of the output files),
> etc. GCC's behaviour is silly and there's no need to replicate it.
>> "The problem with it, however, is that there's a lot more chance for a
>> change to the GCNO file to go unnoticed."
> What do you mean by this? Are you worried that things could go into the
> GCNO file without being an input to the hash function? The checksum is
> a safety measure to help people avoid accidentally putting mismatching
> GCNO and GCDA files together. Not having something be input to the hash
> is the safe failure. We don't want the checksum to change if other
> parts of the GCNO file weren't modified.
What I meant by the last statement was that if you are doing something like hashing the size of the file to compute a checksum, there is a much higher chance that you may be using a GCNO file generated from a different source that just happens to be the same size. Obviously that was just an example, so if you guys came across a better way to seed the hash for Google's gcc checksum, I'd be happy to hear it :)
Anyway, I've taken your arguments to heart and here is a new patch that uses a deterministic approach. Feedback is greatly welcome.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 9691 bytes
Desc: not available
More information about the llvm-commits