<div dir="ltr">On 12 November 2013 16:08, Bob Wilson <span dir="ltr"><<a href="mailto:bob.wilson@apple.com" target="_blank">bob.wilson@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><br>
On Nov 12, 2013, at 4:01 PM, Yuchen Wu <<a href="mailto:yuchenericwu@hotmail.com">yuchenericwu@hotmail.com</a>> wrote:<br>
<br>
> Hi all,<br>
><br>
> So the reason I changed the file checksum to be a timestamp was because gcov was doing the same thing.<br>
<br>
</div>Actually it is GCC that puts the timestamp into the gcno files (at least with the gcc-4.2 that Apple used in the past).<br>
<div class="im"><br>
> 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:<br>
><br>
> 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.<br>
<br>
</div>I prefer this option. I've never heard anyone complain about GCC's timestamps causing problems here.<br></blockquote><div><br></div><div>On the contrary, the gcc google branch has replaced timestamps in gcov files because of the problems is causes us. However, since our gcc team didn't bother to push it to mainline gcc I really can't insist we do the right thing to match gcc.</div>
<div><br></div><div>We run the compiler with --coverage and throw away the .gcno files -- they're in a cache from which they may expire. When viewing coverage data, we may have .gcda data still in the cache but not the .gcno files in which case we run the compiler to regenerate them. Naturally, if you use timestamps this will cause a mismatch ... once you're unlucky enough. I discovered this when I tried using timestamps in this field when adding llvm's gcov support in the first place.</div>
<div><br></div><div>If you insist on timestamps, please add a flag so I can turn them off.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5">
> 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.<br>
</div></div></blockquote><div><br></div><div>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.</div>
<div><br></div>"The problem with it, however, is that there's a lot more chance for a change to the GCNO file to go unnoticed."</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote"><div>Nick</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5">
><br>
> 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.<br>
><br>
> Given these reasons, I think the option 1 is best. What do you think?<br>
><br>
> -Yuchen<br>
><br>
> ----------------------------------------<br>
>> Date: Mon, 11 Nov 2013 14:48:54 -0600<br>
>> From: <a href="mailto:meadori@codesourcery.com">meadori@codesourcery.com</a><br>
>> To: <a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>; <a href="mailto:yuchenericwu@hotmail.com">yuchenericwu@hotmail.com</a><br>
>> CC: <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
>> Subject: Re: [PATCH] llvm-cov: Updated file checksum to be timestamp.<br>
>><br>
>> On 11/11/2013 02:13 PM, Sean Silva wrote:<br>
>><br>
>>> Yes. In general all tool output must be completely deterministic (a timestamp is<br>
>>> "nondeterministic" in the sense that it depends on the (nondeterministic) time<br>
>>> that the tool was built).<br>
>><br>
>> There is always our sneaky friends __TIME__, __DATE__, and __TIMESTAMP__ :-)<br>
>> Incidentally there is a GCC patch just sent out last week [1] to issue a warning<br>
>> when using those macros: <a href="http://gcc.gnu.org/ml/gcc/2013-11/msg00066.html" target="_blank">http://gcc.gnu.org/ml/gcc/2013-11/msg00066.html</a><br>
>><br>
>> --<br>
>> Meador Inge<br>
>> CodeSourcery / Mentor Embedded<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div></div></div>