[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
Mon Dec 7 13:41:16 PST 2020


clayborg added a comment.

So the UUID that ld64 writes out is the MD5 hash of only parts of the binary that do not have debug info paths in them. So you can build the same binary a /tmp/a or in ~/sources/a and get the exact same UUID for the resulting binary.

The nice thing about this is if you use the same compiler and runtime libraries to compile the same sources, you will end up with a consistent UUID from ld64 that is only hashing the .text and .data and other appropriate sections, and it avoids all STAB symbols (which contains the debug map which has source paths and object file paths) that change with where the binary is built. Apple relies on this for their build system so that dSYM files can be uniqued, and if 5 consecutive builds have the same sources and are built with the same compiler, they will not re-upload a new dSYM to their symbol server, they will re-use the same dSYM.

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.

LLDB only uses the UUID to find the matching dSYM when loading debug symbols, so nothing will affect LLDB's ability to use the UUID no matter how it is generated. The main question is do we want to mimic what ld64 is doing or not by having a consistent UUID that depends on the contents of the file that won't change if the binary is built in different source roots.


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

https://reviews.llvm.org/D92736



More information about the llvm-commits mailing list