[lldb-dev] Handling of the ELF files missing build-ids?

[Leonard Mosescu via lldb-dev]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180803/6da4cad2/attachment-0001.html>