Knowledge from mcgrathr:

> There is no requirement that build IDs be generated in any one particular
> way--there is just an underspecified requirement that they be "unique
> enough".  The "canonical" one is what's implemented by --build-id=sha1
> (aka --build-id by default in BFD ld), which is a hash across the
> whole output file and so becomes a serializing operation at the end of
> the link.  Gold implements another scheme available under
> --build-id=tree (which became the default for gold in binutils-2.24,
> so it should be what we are using now in Chromium) , which is intended
> also to be reliably reproducible but to be implementable with much
> less serialization.  If you didn't care about reproducibility, it
> would be entirely valid to use some other scheme like --build-id=uuid,
> which just uses a random bit string (long enough to be presumed
> universally unique), and thus is generated in constant time.  The
> tools also support --build-id=0x... so that you can precompute a value
> in whatever fashion you choose (however many bytes long you like,
> though the SHA1 length is what's usually used) and just store exactly
> that at link time (which of course is also constant time).

I don't think there's any reason that we need to use sha1 build-ids. Let's see how much faster --build-id=UUID and --build-id=tree make our link times.