<div dir="ltr"><div>Greg, Mark,</div><div><br></div>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. <div><br></div><div>But there are a few problems with this approach:</div><div><br></div><div>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.</div><div>- especially when some unstripped binaries can be very large. for example a local chromium build produces a 5.3Gb chrome binary </div><div>- the crc32 implementation is decent, but single-threaded</div><div>- 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</div><div><br></div><div>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)</div><div>- an example is Breakpad, which unfortunately also attempts to make up UUIDs when the build-id is missing (something we'll hopefully fix soon)</div><div><br></div><div>Is there a fundamental reason to calculate the full file crc32? If not I propose to improve this based on the following observations:</div><div><br></div><div>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.</div><div>B. The full file name should be enough to prove the identity of a local module.</div><div>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)</div><div><br></div><div>What do you think?</div><div><br></div><div>Thanks,</div><div>Lemo.</div><div><br></div></div>