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

Greg Clayton via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 8 14:32:20 PST 2020


clayborg added a comment.

In D92736#2439612 <https://reviews.llvm.org/D92736#2439612>, @thakis wrote:

>>> 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?
>>
>> We have cases where the ELF build ID changes on us for binaries when we have stripped debug info. Debuggers really want to match a stripped binary to a non stripped binary.
>
> This is where I don't follow. My mental model is:
>
> 1. Build with symbols, upload that binary to some symbol server
> 2. Run `strip`
> 3. Ship the stripped binary to production (users, data centers, whatever)
>
> `strip` doesn't change the UUID, it leaves it in place unchanged (...right?). So stripped and non-stripped binary always have a matching UUID in this case. Having a strip-invariant hash algorithm matters if you do something like:
>
> 1. Build with symbols, upload that binary to some symbol server
> 2. Independently build the same binary at the same revision, but without symbols
> 3. Ship the binary from 2 to production
>
> In that case, if you want the binaries in 1 and 2 to have the same UUID you do need a hashing algorithm like the one you describe. Is the second workflow what you're doing? Or is there something else I'm missing?

The point is if you produce a binary with ld64 with or without local symbols, with or without debug info (STABS debug map) -- at link time -- it will produce the same UUID. This isn't the case for ELF files as the UUID is based off of the binary contents at build time. ld64 takes only the parts that don't change and makes a hash of those bits only.


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

https://reviews.llvm.org/D92736



More information about the llvm-commits mailing list