[all-commits] [llvm/llvm-project] a1e979: Have kernel binary scanner load dSYMs as binary+dS...

[Jason Molenda via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: a1e97923a025d09934b557ca4343d8e4b5a9973d
      https://github.com/llvm/llvm-project/commit/a1e97923a025d09934b557ca4343d8e4b5a9973d
  Author: Jason Molenda <jason at molenda.com>
  Date:   2020-10-01 (Thu, 01 Oct 2020)

  Changed paths:
    M lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
    M lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp
    M lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
    M lldb/source/Plugins/Platform/MacOSX/PlatformMacOSXProperties.td

  Log Message:
  -----------
  Have kernel binary scanner load dSYMs as binary+dSYM if best thing found

lldb's PlatforDarwinKernel scans the local filesystem (well known
locations, plus user-specified directories) for kernels and kexts
when doing kernel debugging, and loads them automatically.  Sometimes
kernel developers want to debug with *only* a dSYM, in which case they
give lldb the DWARF binary + the dSYM as a binary and symbol file.
This patch adds code to lldb to do this automatically if that's the
best thing lldb can find.

A few other bits of cleanup in PlatformDarwinKernel that I undertook
at the same time:

1. Remove the 'platform.plugin.darwin-kernel.search-locally-for-kexts'
setting.  When I added the local filesystem index at start of kernel
debugging, I thought people might object to the cost of the search
and want a way to disable it.  No one has.

2. Change the behavior of
'plugin.dynamic-loader.darwin-kernel.load-kexts' setting so it does
not disable the local filesystem scan, or use of the local filesystem
binaries.

3. PlatformDarwinKernel::GetSharedModule into GetSharedModuleKext and
GetSharedModuleKernel for easier readability & maintenance.

4. Added accounting of .dSYM.yaa files (an archive format akin to tar)
that I come across during the scan.  I'm not using these for now; it
would be very expensive to expand the archives & see if the UUID matches
what I'm searching for.

<rdar://problem/69774993>
Differential Revision: https://reviews.llvm.org/D88632