<div dir="ltr"><div class="gmail_extra">I sent out <a href="http://reviews.llvm.org/D18091">http://reviews.llvm.org/D18091</a> for review. It implements FNV1 hash.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 11, 2016 at 9:37 AM, Ed Maste <span dir="ltr"><<a href="mailto:emaste@freebsd.org" target="_blank">emaste@freebsd.org</a>></span> wrote:<br><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"><span class="">On 11 March 2016 at 11:56, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> Non-secure hash function such as FNV1 can be written in 10 lines of code or<br>
> so, so we don't necessarily have to use ADT/Hashing.h.<br>
><br>
> The question is whether we need to use a secure hash or not. If we can<br>
> accept a collision of build ID (although it's a very low probability), we<br>
> should use a non-secure hash. If not, we need to use a secure hash. It seems<br>
> to me that everybody's basically okay with a very low probability of<br>
> collision for the sake of performance? So here's my plan.<br>
><br>
>  - Use a fast non-secure hash function as default for --build-id<br>
>  - Implement --build-id=md5 (GNU ld and gold both have this option) so that<br>
> users can choose the secure hash function<br>
><br>
> Any objections/concerns?<br>
<br>
</span>This sounds broadly fine to me.<br>
<br>
Note that ld.bfd and gold support md5, sha1, and a 128-bit random<br>
number ("uuid"). sha1 seems to be the default for both ld.bfd and<br>
gold, and if we implement only one "secure" hash I think that should<br>
be it.<br>
<br>
Gold also has a mode that parallelizes by hashing chunks of the output<br>
file, and then hashing those hashes. It's unfortunate to expose so<br>
many options to the user though. I'm not sure what makes the most<br>
sense for us with respect to providing useful knobs, and bfd/gold<br>
compatibility. In my ideal world we'd have only one option in lld<br>
that's both fast and secure.<br>
<br>
One other item to consider, some tools make expectations about the<br>
size of the build-id data. For example, "file" uses the size to report<br>
the putative algorithm used. It reports "sha1" for a 20-byte build-id<br>
and "md5/uuid" for a 16-byte build-id.<br>
<br>
% cc -fuse-ld=gold -Wl,--build-id hello.c<br>
% file a.out<br>
a.out: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD),<br>
dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 10.1<br>
(1001507), BuildID[sha1]=74c58ef86747a092d357a42cc106eb4688e15333, not<br>
stripped<br>
%<br></blockquote><div><br></div><div>The build-id note section has the size field for the build-id so that any tools that reads an ID is able to know the size of it. In our case, because it is 64-bit FNV1, it's set to 8 (byte.)</div><div> </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">
In any case I'd be happy with what you describe above, but with a<br>
small preference for sha1 over md5.<br>
</blockquote></div><br></div></div>