<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 11, 2016 at 11:49 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 11 March 2016 at 13:32, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:<br>
> I sent out <a href="http://reviews.llvm.org/D18091" rel="noreferrer" target="_blank">http://reviews.llvm.org/D18091</a> for review. It implements FNV1<br>
> hash.<br>
<br>
</span>Great! I've applied it locally and am testing it out.<br>
<span><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>
</span>>> [...]<br>
<span>>><br>
> The build-id note section has the size field for the build-id so that any<br>
> tools that reads an ID is able to know the size of it. In our case, because<br>
> it is 64-bit FNV1, it's set to 8 (byte.)<br>
<br>
</span>Right, I just mean that some tools aren't prepared to handle a<br>
build-id note that is not either 16 or 20 bytes. For example, with an<br>
8-byte build ID file doesn't report anything. This is arguably a file<br>
bug, but I wouldn't be surprised if some other tools behave the same<br>
way.<br>
</blockquote></div><br></div><div class="gmail_extra">It doesn't seem to make sense to leave 8 byte blank in the .note section. I'd think that setting the size to 8 byte conveys the message that there is a chance of collision, too. So I guess that keeping it 8 bytes is a good idea.</div></div>