[PATCH] llvm-cov: Updated file checksum to be timestamp.
yuchenericwu at hotmail.com
Tue Nov 12 16:01:49 PST 2013
So the reason I changed the file checksum to be a timestamp was because gcov was doing the same thing. I understand that makes it non-deterministic but the alternatives aren't really that much better. The way I see it there are three options:
1. Using the timestamp as a seed to a hash function which will determine the checksum. This means that two checksums will never have the same value. This can be viewed as a bad thing since it's non-deterministic, but the advantage being there won't be any collision problems and makes it impossible for the user to use out of sync GCNO and GCDA files. An addendum to this could be that the user could opt to specify a seed instead of the timestamp if the output must be deterministic, which is what gcov does.
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.
3. Keep using "LLVM" as the checksum. The only benefit from this is that it's easy to tell the version was generated from clang.
Given these reasons, I think the option 1 is best. What do you think?
> Date: Mon, 11 Nov 2013 14:48:54 -0600
> From: meadori at codesourcery.com
> To: silvas at purdue.edu; yuchenericwu at hotmail.com
> CC: llvm-commits at cs.uiuc.edu
> Subject: Re: [PATCH] llvm-cov: Updated file checksum to be timestamp.
> On 11/11/2013 02:13 PM, Sean Silva wrote:
>> Yes. In general all tool output must be completely deterministic (a timestamp is
>> "nondeterministic" in the sense that it depends on the (nondeterministic) time
>> that the tool was built).
> There is always our sneaky friends __TIME__, __DATE__, and __TIMESTAMP__ :-)
> Incidentally there is a GCC patch just sent out last week  to issue a warning
> when using those macros: http://gcc.gnu.org/ml/gcc/2013-11/msg00066.html
> Meador Inge
> CodeSourcery / Mentor Embedded
More information about the llvm-commits