48a12ae821
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
12 KiB
12 KiB