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

[Mark Wielaard]

Hi Frank,

On Thu, 2024-09-19 at 18:40 -0400, Frank Ch. Eigler wrote:
> diff --git a/ld/configure.ac b/ld/configure.ac
> index bdf51a062fa0..7b19c0b9c330 100644
> --- a/ld/configure.ac
> +++ b/ld/configure.ac
> @@ -424,6 +424,27 @@ if test $ld_cv_decl_getopt_unistd_h = yes; then
>  	    [Is the prototype for getopt in <unistd.h> in the expected format?])
>  fi
>  
> +dnl xxhash support from gdbsupport/common.m4
> +AC_MSG_CHECKING([whether to use xxhash])
> +AC_ARG_WITH(xxhash,
> +  AS_HELP_STRING([--with-xxhash], [use inlined libxxhash for hashing (faster) (auto/yes/no)]),
> +  [], [with_xxhash=auto])
> +if test "x$with_xxhash" != "xno"; then
> +  AC_COMPILE_IFELSE([AC_LANG_SOURCE([
> +#define XXH_INLINE_ALL
> +#include <xxhash.h>
> +int main() { return XXH32("foo", 3, 0); }
> +])],[
> +  with_xxhash=yes
> +  AC_DEFINE([WITH_XXHASH], 1, [whether to use inline xxhash])
> +],[
> +  if test "$with_xxhash" = yes; then
> +    AC_MSG_ERROR([xxhash is missing or unusable])
> +  fi
> +  with_xxhash=no])
> +fi
> +AC_MSG_RESULT([$with_xxhash])
> +
>  # Link in zlib/zstd if we can.  This allows us to read and write
>  # compressed debug sections.
>  AM_ZLIB

I think you want to explicitly test for XXH3_createState (or any other
XXH3/XXH128 function introduced in 0.8.0. Previous versions might have
XXH32, but not XXH3/XXH128 support.

> @@ -100,7 +122,28 @@ generate_build_id (bfd *abfd,
>  		   unsigned char *id_bits,
>  		   int size ATTRIBUTE_UNUSED)
>  {
> -  if (streq (style, "md5"))
> +#ifdef WITH_XXHASH
> +  if (streq (style, "xx"))
> +    {
> +      XXH3_state_t* state = XXH3_createState();
> +      if (!state)
> +        {
> +          return false;
> +        }
> +      XXH3_128bits_reset (state);
> +      if (!(*checksum_contents) (abfd, &xx_process_bytes, state))
> +        {
> +          XXH3_freeState (state);
> +          return false;
> +        }
> +      XXH128_hash_t result = XXH3_128bits_digest (state);
> +      XXH3_freeState (state);
> +      memcpy (id_bits, &result,
> +	      (size_t) size < sizeof (result) ? (size_t) size : sizeof (result));
> +    }
> +  else
> +#endif
> +    if (streq (style, "md5"))
>      {
>        struct md5_ctx ctx;

Is the result a integral value or a byte array?
Does it generate the same result on little/big endian setup?
If not do we want to byteswap it before writing it out?

Or maybe always use big or little endian encoding to get consistent
results even when the runtime endianness and the file endianness are
different? I note there is XXH128_canonicalFromHash.

Cheers,

Mark