Eng/r109186357 various macho corefile loading fixes and perf improvements 59 #6940
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Follow Alex Langford's feedback to my patch from https://reviews.llvm.org/D145547 , and fix a side issue I noticed while testing this, where binaries loaded via LC_NOTE metadata were loaded in the Target twice unnecessarily. (cherry picked from commit 8db8a4e)
When ObjectFileMachO::LoadCoreFileImages load a binary into the target with a valid load address, we don't need to re-load its segments into the Target's SectionLoadList again. But we should still call ModulesDidLoad on these modules so breakpoints can be inserted etc. (cherry picked from commit 7f25c3e)
In ProcessMachCore::LoadBinariesViaMetadata(), if we did load some binaries via metadata in the core file, don't then search for a userland dyld in the corefile / kernel and throw away that binary list. Also fix a little bug with correctly recognizing corefiles using a `main bin spec` LC_NOTE that explicitly declare that this is a userland corefile. LocateSymbolFileMacOSX.cpp's Symbols::DownloadObjectAndSymbolFile clarify the comments on how the force_lookup and how the dbgshell_command local both have the same effect. In PlatformDarwinKernel::LoadPlatformBinaryAndSetup, don't log a message unless we actually found a kernel fileset. Reorganize ObjectFileMachO::LoadCoreFileImages so that it delegates binary searching to DynamicLoader::LoadBinaryWithUUIDAndAddress and doesn't duplicate those searches. For searches that fail, we would perform them multiple times in both methods. When we have the mach-o segment vmaddrs for a binary, don't let LoadBinaryWithUUIDAndAddress load the binary first at its mach-o header address in the Target; we'll load the segments at the correct addresses individually later in this method. DynamicLoaderDarwin::ImageInfo::PutToLog fix a LLDB_LOG logging formatter. In DynamicLoader::LoadBinaryWithUUIDAndAddress, instead of using Target::GetOrCreateModule as a way to find a binary already registered in lldb's global module cache (and implicitly add it to the Target image list), use ModuleList::GetSharedModule() which only searches the global module cache, don't add it to the Target. We may not want to add an unstripped binary to the Target. Add a call to Symbols::DownloadObjectAndSymbolFile() even if "force_symbol_search" isn't set -- this will turn into a DebugSymbols call / Spotlight search on a macOS system, which we want. Only set the Module's LoadAddress if the caller asked us to do that. Differential Revision: https://reviews.llvm.org/D150928 rdar://109186357 (cherry picked from commit 48a12ae)
|
@swift-ci please test |
jasonmolenda
deleted the
eng/r109186357-various-macho-corefile-loading-fixes-and-perf-improvements-59
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.