<div dir="ltr">Non-secure hash function such as FNV1 can be written in 10 lines of code or so, so we don't necessarily have to use ADT/Hashing.h.<div><br></div><div>The question is whether we need to use a secure hash or not. If we can accept a collision of build ID (although it's a very low probability), we should use a non-secure hash. If not, we need to use a secure hash. It seems to me that everybody's basically okay with a very low probability of collision for the sake of performance? So here's my plan.</div><div><br></div><div> - Use a fast non-secure hash function as default for --build-id</div><div> - Implement --build-id=md5 (GNU ld and gold both have this option) so that users can choose the secure hash function</div><div><br></div><div>Any objections/concerns?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 11, 2016 at 8:33 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11 March 2016 at 00:16, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> hash_value in ADT/Hashing is pretty fast that self link time increased from<br>
> 0.6453 to 0.6604 seconds (in wall clock time), so it's within a few percent<br>
> increase. Very interesting result, but I'm not still sure if it's what<br>
> people expect on --build-id.<br>
<br>
</span>Note that unfortunately ADT/Hashing.h is not reproducible. In<br>
particular, it produces different results in 32 and 64 bit machines.<br>
<br>
It would be nice to refactor it so that the same algorithm can be used<br>
for both "fast, but not reproducible" and "not as fast, but<br>
reproducible" cases.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>