[Lldb-commits] [PATCH] D157167: [lldb] Add flag to DynamicLoader::LoadBinaryWithUUIDAndAddress to control whether we fall back to reading the binary out of memory

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda created this revision.
jasonmolenda added reviewers: bulbazord, JDevlieghere.
jasonmolenda added a project: LLDB.
Herald added a project: All.
jasonmolenda requested review of this revision.
Herald added subscribers: lldb-commits, wangpc.

DynamicLoader::LoadBinaryWithUUIDAndAddress() tries a few different ways of finding a binary, and if it can't find an actual binary (and symbol file) on the local computer, it will try to read a binary out of memory, with the thought that there may be a symbol table in memory so we'll get some symbol names.  It will create a placeholder name of `memory-image-0x...`.  It seemed like a good idea when I wrote this method, but in practice for binaries outside of userland binaries in a corefile, this hasn't been helpful.

This patch adds a flag to LoadBinaryWithUUIDAndAddress to control if we should create a memory image module, or not.  The only case where we still enable this behavior is in ObjectFileMachO::LoadCoreFileImages() when a binary has segment load addresses.  This is the case with the "all image infos" LC_NOTE that lldb creates for userland corefiles with binaries that typically have some symbols in their in-memory symbol tables.

The other type of userland corefiles (gcore-created) will not use this LC_NOTE but an entirely different codepath -- through the Darwin userland DynamicLoader plugin -- is taken in those cases, so we'll still read them out of memory.

This patch makes firmware/standalone binary loading not create these `memory-image-0x...` placeholder binaries with no symbols in them, the scenario where it is more annoying than useful.

The test case TestMultipleBinaryCorefile.py tests this standalone-binary corefile scenario, so it needed adjusting to the new setup where the binary image is not added to the target.  I also cleaned up the fake dsym-for-uuid.sh it creates to return a properly formatted DBGError message for https://reviews.llvm.org/D157160


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D157167

Files:
  lldb/include/lldb/Target/DynamicLoader.h
  lldb/source/Core/DynamicLoader.cpp
  lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
  lldb/test/API/macosx/lc-note/multiple-binary-corefile/TestMultipleBinaryCorefile.py
  lldb/test/API/macosx/lc-note/multiple-binary-corefile/create-multibin-corefile.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D157167.547420.patch
Type: text/x-patch
Size: 13164 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20230805/321f1c99/attachment-0001.bin>