[all-commits] [llvm/llvm-project] 430e14: Clean up PlatformDarwinKernel::GetSharedModule, do...

[Jason Molenda via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 430e145fc3964dac0bbf355f27616190d403dd83
      https://github.com/llvm/llvm-project/commit/430e145fc3964dac0bbf355f27616190d403dd83
  Author: Jason Molenda <jmolenda at apple.com>
  Date:   2024-01-18 (Thu, 18 Jan 2024)

  Changed paths:
    M lldb/include/lldb/Target/Platform.h
    M lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp

  Log Message:
  -----------
  Clean up PlatformDarwinKernel::GetSharedModule, document (#78652)

PlatformDarwinKernel::GetSharedModule, which can find a kernel or kext
from a local filesystem scan, needed a little cleanup. The method which
finds kernels was (1) not looking for the SymbolFileSpec when creating a
Module, and (2) adding that newly created Module to a Target, which
GetSharedModule should not be doing - after auditing many other subclass
implementations of this method, I haven't found any others doing it.
Platform::GetSharedModule didn't have a headerdoc so it took a little
work to piece together the intended behaviors.

This is addressing a bug where
PlatformDarwinKernel::GetSharedModuleKernel would find the ObjectFile
for a kernel, create a Module, and add it to the Target. Then up in
DynamicLoaderDarwinKernel, it would check if the Module had a SymbolFile
FileSpec, and because it did not, it would do its own search for a
binary & dSYM, find them, and then add that to the Target. Now we have
two copies of the Module in the Target, one with a dSYM and the other
without, and only one of them has its load addresses set.

GetSharedModule should not be adding binaries to the Target, and it
should set the SymbolFile FileSpec when it is creating the Module.

rdar://120895951