Fix ProcessElfCore::FindModuleUUID() so it work with symlinks. (#206601)
Resumbitting https://github.com/llvm/llvm-project/pull/205235 with
disabled parallel module loading to fix buildbot deadlock.
ProcessElfCore was reading the NT_FILE list and using that to help
FindModuleUUID to provide UUID information when loading core files. The
NT_FILE list contains resolved paths only, while the
DynamicLoaderPOSIXDYLD plug-in was using paths found in the r_debug
structure which contains a linked list of all of the shared libraries in
a process. The issue was these paths could be symlinks which would cause
ProcessELFCore::FindModuleUUID(...) to fail because the paths wouldn't
match up. This led to the ProcessELFCore often not being able to provide
UUIDs for shared libraries and cause the incorrect binaries to be loaded
from the current machine even when the shared library UUIDs don't match.
The solution was to add the ability for a ModuleSpec to contain a load
address for the shared library. This allows ProcessELFCore to uniquely
identify a library regardless of the name used in NT_FILE. We can now
correctly supply the UUID from the .gnu-build-id to any binaries which
use symlinks when linking, but have differing resolved paths to the
libraries.
The process virtual function for finding a UUID was changed from:
virtual lldb_private::UUID FindModuleUUID(const llvm::StringRef path);
to:
virtual bool FindModuleUUID(ModuleSpec &spec);
to allow Process::FindModuleUUID to rely on other data in the ModuleSpec
since the path isn't enough.
We will be able to use the ModuleSpec's load address for creating a
module from a ModuleSpec, but that isn't in this PR.
llvm-project
45afced2 - Fix ProcessElfCore::FindModuleUUID() so it work with symlinks. (#206601)
