[patch rfc]: use xxhash() in ld build-id computation, incl. benchmark

[Frank Ch. Eigler]

Hi -

Thanks for your response!

> Introducing a new --build-id= value requires the ecosystem to adapt.

I'm not sure I see why.  Build-ids for any given binary may be
computed or set any way at all, independent of other binaries or the
rest of the ecosystem.

> Therefore, lld/mold's --build-id=fast never gets wide adoption.

I'm not sure whether why that would be or why it should be a
consideration for an improvement in binutils.

> sha1 is 160 bits, wider than 128 bits, which many fast hash
> implementations support.  lld and mold truncate BLAKE3's 256-bit
> digest to 128/160 for md5/sha1 :)

Digest width is an interesting question, yes.  I don't recall which
newfangled linker it was, but some years ago, someone proposed that it
should use an 8-byte (64-bit) buildid, because of speed.  We were not
a big fan.

We did some calculations and some checking of the debuginfod buildid
corpus (which as of today includes ~100 million distinct buildids in
the public federated servers).  That starts to come foreseeably close
to 32-bits, and considering the birthday paradox, needing at least 64
bits to reliably tell apart.  But 128 bits ought to be enough for
anybody.


- FChE