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

[Nick Clifton]

Hi Guys,

On 11/29/23 13:40, Michael Matz wrote:
> OTOH: descriptive names might be a bikeshed hellhole :)  What if we were
> to add a say "secure" and a "fast" name now.  But how to somehow document
> how much less "secure" (whatever that means in this context) the fast
> variant is?  And how much faster is it?  And what if someone comes and
> implements a fast version of secure that happens to be even faster?  Call
> it "secure-and-even-faster-than-old-fast"? ;-)  Hmm hmm.

Yes it is all relative really.


Thinking about a "fast" build-id I did have an off the wall idea for people
who want to improve the current linker's speed without having to patch the
code.  Would the following work:

   1. Link, but instead of --build-id=sha1 use --build-id=0x<160-bit-hex-number>
   2. Afterward run an optimized digest generating program (eg sha1sum) on the
      the resulting binary.
   3. Use GNU poke (or some similar tool) to store the computed digest into the
      the .note.gnu.build-id section.

My theory is that a stand-alone digest generating program could be a lot faster
than the sha1 algorithm currently used by the linker.  I have no idea if this
would actually work in practice, but it did seem appealing in that it does not
involve changing any of the already existing tools.

Cheers
   Nick


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x13FCEF89DD9E3C4F.asc
Type: application/pgp-keys
Size: 3106 bytes
Desc: OpenPGP public key
URL: <https://sourceware.org/pipermail/binutils/attachments/20231130/7c3f8b56/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/binutils/attachments/20231130/7c3f8b56/attachment-0001.sig>