[PATCH] libiberty, ld: Use x86 HW optimized sha1

[Michael Matz]

Hello,

On Tue, 28 Nov 2023, Nick Clifton wrote:

> > Note, seems lld uses BLAKE3 rather than md5/sha1. 
> 
> It also allows users to use the xxHash alogirthm as well (athough it
> calls it "Fast").  It would be nice if libiberty could support both
> of these algorithms.

What mold is using is to depend on libcrypto of openssl and call its SHA 
routines which are heavily optimized (even the ones that don't depend on 
special instructions are _much much_ faster than the ones in libiberty).

(What it actually does is to always call the SHA256 routines, and for 
=sha1 output it simply cuts off some bytes from the result.  The libcrypto 
sha256 routines are still many times faster than the sha1 routines in 
libiberty).

(Replace libcrypto with the equivalents of libressl or libnettle)

> > I think it would be a bad idea to lie to users, if they choose 
> > --buildid=sha1, we should be using SHA1, not some other checksum,
> 
> Agreed.

In principle I agree, but OTOH it's not so super clear cut: when you 
actually want to depend on what --build-id=xyz produces (e.g. for 
post-build checks), then you don't only need the specific hash algorithm.  
You also need to know how exactly it's applied: which pieces of the input 
file go into hashing, in which order, and which length.  All linkers 
do that differently right now, so even with the same hash algo they would 
produce different checksums.

What matters for build-id is that the same input generates the same 
checksum, and different inputs likely don't generate the same checksum.
In that sense our naming of the build-id strategies should rather be 
something like "quick" and "thorough" or "cryptographic".  Naming a 
specific algorithm implies something dependable that actually isn't so 
dependable after all.


Ciao,
Michael.