[PATCH] D92736: [lld/mac] Use xxhash instead of MD5 for computing the UUID

Nico Weber via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 7 15:40:53 PST 2020


thakis added a comment.

Thanks! There's two mostly independent questions here.

1. Choice of hash function. The patch changes the hash function but doesn't modify what parts of the binary get hashed:

> So if we change the UUID to be unique on each build, we can probably guarantee that Apple won't ever use lld for their builds. Not sure how important this is. This also means that if a UUID is generated by ld64 for a stripped or non-stripped binary, it will end up being the same, which is nice.

That's not what this patch is doing. It changes only which hash function we use, not which ranges of the binary we hash.

2. Output binary determinism.

I agree that this is an important goal. It is independent of this patch.

You can get the benefit of build-dir-independence without hacking up the linker, see "Getting to local determinism" on https://blog.llvm.org/2019/11/deterministic-builds-with-clang-and-lld.html , in particular the `-fdebug-compilation-dir` bits. That's important to get `.o` files that are independent of the build dir as well, which in turn is important for distcc-like systems that can reuse `.o` caches across users / bots, independent of build dir.

Is stripped builds and non-stripped builds having the same UUID something that's useful in practice? I would've expected that everyone builds a debug binary with symbols, and then strips it after building. What's the use case for links with and without debug info and wanting the same UUID?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92736/new/

https://reviews.llvm.org/D92736



More information about the llvm-commits mailing list