[all-commits] [llvm/llvm-project] 57cbd2: Flag for LoadBinaryWithUUIDAndAddress, to create m...

[Jason Molenda via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 57cbd26a68ab61631f5f4272d3c90df2eb0ce4f6
      https://github.com/llvm/llvm-project/commit/57cbd26a68ab61631f5f4272d3c90df2eb0ce4f6
  Author: Jason Molenda <jason at molenda.com>
  Date:   2023-08-07 (Mon, 07 Aug 2023)

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

  Log Message:
  -----------
  Flag for LoadBinaryWithUUIDAndAddress, to create memory image or not

DynamicLoader::LoadBinaryWithUUIDAndAddress can create a Module based
on the binary image in memory, which in some cases contains symbol
names and can be genuinely useful.  If we don't have a filename, it
creates a name in the form `memory-image-0x...` with the header address.

In practice, this is most useful with Darwin userland corefiles
where the binary was stored in the corefile in whole, and we can't
find a binary with the matching UUID.  Using the binary out of
the corefile memory in this case works well.

But in other cases, akin to firmware debugging, we merely end up
with an oddly named binary image and no symbols.

Add a flag to control whether we will create these memory images
and add them to the Target or not; only set it to true when working
with a userland Mach-O image with the "all image infos" LC_NOTE for
a userland corefile.

Differential Revision: https://reviews.llvm.org/D157167