aboutsummaryrefslogtreecommitdiff
path: root/llvm/tools/llvm-cov/SourceCoverageView.cpp
diff options
context:
space:
mode:
authorJason Molenda <jmolenda@apple.com>2024-01-18 23:26:15 -0800
committerGitHub <noreply@github.com>2024-01-18 23:26:15 -0800
commit430e145fc3964dac0bbf355f27616190d403dd83 (patch)
tree41ecf5f3c706df894eabb21bfa91313981d1034f /llvm/tools/llvm-cov/SourceCoverageView.cpp
parent498e1c2257da552abc58aa75f6b9f776bf826f86 (diff)
downloadllvm-430e145fc3964dac0bbf355f27616190d403dd83.zip
llvm-430e145fc3964dac0bbf355f27616190d403dd83.tar.gz
llvm-430e145fc3964dac0bbf355f27616190d403dd83.tar.bz2
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
Diffstat (limited to 'llvm/tools/llvm-cov/SourceCoverageView.cpp')
0 files changed, 0 insertions, 0 deletions