Greg, Mark, Looking at the code, LLDB falls back to a full file crc32 to create the module UUID if the ELF build-id is missing. This works, in the sense that the generated UUID does indeed identify the module.
But there are a few problems with this approach: 1. First, runtime performance: a full file crc32 is a terribly inefficient way to generate a temporary UUID that is basically just used to match a local file to itself. - especially when some unstripped binaries can be very large. for example a local chromium build produces a 5.3Gb chrome binary - the crc32 implementation is decent, but single-threaded - to add insult to the injury, it seems a small bug defeats the intention to cache the hash value so it ends up being recalculated multiple times 2. The fake UUID is not going to match any external UUID that may be floating around (and yet not properly embedded into the binary) - an example is Breakpad, which unfortunately also attempts to make up UUIDs when the build-id is missing (something we'll hopefully fix soon) Is there a fundamental reason to calculate the full file crc32? If not I propose to improve this based on the following observations: A. Model the reality more accurately: an ELF w/o a build-id doesn't really have an UUID. So use a zero-length UUID in LLDB. B. The full file name should be enough to prove the identity of a local module. C. If we try to match an external UUID (ex. from a minidump) with a local file which does not have an UUID it may help to have an option to allow it to match (off by default, and only if there's no better match) What do you think? Thanks, Lemo.
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
