[lldb] Stop passing both i386 and i686 in parallel as architectures on WindowsWhen an object file returns multiple architectures, it is treatedas a fat binary - which really isn't the case of i386
[lldb] Stop passing both i386 and i686 in parallel as architectures on WindowsWhen an object file returns multiple architectures, it is treatedas a fat binary - which really isn't the case of i386 vs i686 wherethe object file actually has one architecture.This allows getting rid of hardcoded architecture triples inPlatformWindows.The parallel i386 and i686 architecture strings stem from5e6f45201f0b62c1e7a24fc396f3ea6e10dc880d / D7120 andad587ae4ca143d388c0ec4ef2faa1b5eddedbf67 / D4658.Differential Revision: https://reviews.llvm.org/D128617
show more ...
[lldb] Change CreateMemoryInstance to take a WritableDataBufferChange the CreateMemoryInstance interface to take a WritableDataBuffer.Differential revision: https://reviews.llvm.org/D123073
[lldb] Prevent object file plugins from changing the data bufferThe current design allows that the object file contents could be mappedby one object file plugin and then used by another. Presumabl
[lldb] Prevent object file plugins from changing the data bufferThe current design allows that the object file contents could be mappedby one object file plugin and then used by another. Presumably the ideahere was to avoid mapping the same file twice.This becomes an issue when one object file plugin wants to map the filedifferently from the others. For example, ObjectFileELF needs to map itsmemory as writable while others likeObjectFileMachO needs it to bemapped read-only.This patch prevents plugins from changing the buffer by passing them isby value rather than by reference.Differential revision: https://reviews.llvm.org/D122944
[NFC] Fix endif comments to match with include guard
[NFC] Refactor symbol table parsing.Symbol table parsing has evolved over the years and many plug-ins contained duplicate code in the ObjectFile::GetSymtab() that used to be pure virtual. With this
[NFC] Refactor symbol table parsing.Symbol table parsing has evolved over the years and many plug-ins contained duplicate code in the ObjectFile::GetSymtab() that used to be pure virtual. With this change, the "Symbtab *ObjectFile::GetSymtab()" is no longer virtual and will end up calling a new "void ObjectFile::ParseSymtab(Symtab &symtab)" pure virtual function to actually do the parsing. This helps centralize the code for parsing the symbol table and allows the ObjectFile base class to do all of the common work, like taking the necessary locks and creating the symbol table object itself. Plug-ins now just need to parse when they are asked to parse as the ParseSymtab function will only get called once.This is a retry of the original patch https://reviews.llvm.org/D113965 which was reverted. There was a deadlock in the Manual DWARF indexing code during symbol preloading where the module was asked on the main thread to preload its symbols, and this would in turn cause the DWARF manual indexing to use a thread pool to index all of the compile units, and if there were relocations on the debug information sections, these threads could ask the ObjectFile to load section contents, which could cause a call to ObjectFileELF::RelocateSection() which would ask for the symbol table from the module and it would deadlock. We can't lock the module in ObjectFile::GetSymtab(), so the solution I am using is to use a llvm::once_flag to create the symbol table object once and then lock the Symtab object. Since all APIs on the symbol table use this lock, this will prevent anyone from using the symbol table before it is parsed and finalized and will avoid the deadlock I mentioned. ObjectFileELF::GetSymtab() was never locking the module lock before and would put off creating the symbol table until somewhere inside ObjectFileELF::GetSymtab(). Now we create it one time inside of the ObjectFile::GetSymtab() and immediately lock it which should be safe enough. This avoids the deadlocks and still provides safety.Differential Revision: https://reviews.llvm.org/D114288
Revert "[NFC] Refactor symbol table parsing."This reverts commit 951b107eedab1829f18049443f03339dbb0db165.Buildbots were failing, there is a deadlock in /Users/gclayton/Documents/src/llvm/clean/l
Revert "[NFC] Refactor symbol table parsing."This reverts commit 951b107eedab1829f18049443f03339dbb0db165.Buildbots were failing, there is a deadlock in /Users/gclayton/Documents/src/llvm/clean/llvm-project/lldb/test/Shell/SymbolFile/DWARF/DW_AT_range-DW_FORM_sec_offset.s when ELF files try to relocate things.
[NFC] Refactor symbol table parsing.Symbol table parsing has evolved over the years and many plug-ins contained duplicate code in the ObjectFile::GetSymtab() that used to be pure virtual. With this change, the "Symbtab *ObjectFile::GetSymtab()" is no longer virtual and will end up calling a new "void ObjectFile::ParseSymtab(Symtab &symtab)" pure virtual function to actually do the parsing. This helps centralize the code for parsing the symbol table and allows the ObjectFile base class to do all of the common work, like taking the necessary locks and creating the symbol table object itself. Plug-ins now just need to parse when they are asked to parse as the ParseSymtab function will only get called once.Differential Revision: https://reviews.llvm.org/D113965
[lldb] Remove ConstString from GetPluginNameStatic of some pluginsThis patch deals with ObjectFile, ObjectContainer and OperatingSystemplugins. I'll convert the other types in separate patches.I
[lldb] Remove ConstString from GetPluginNameStatic of some pluginsThis patch deals with ObjectFile, ObjectContainer and OperatingSystemplugins. I'll convert the other types in separate patches.In order to enable piecemeal conversion, I am leaving some ConstStringsin the lowest PluginManager layers. I'll convert those as the last step.Differential Revision: https://reviews.llvm.org/D112061
[lldb] Return StringRef from PluginInterface::GetPluginNameThere is no reason why this function should be returning a ConstString.While modifying these files, I also fixed several instances where
[lldb] Return StringRef from PluginInterface::GetPluginNameThere is no reason why this function should be returning a ConstString.While modifying these files, I also fixed several instances whereGetPluginName and GetPluginNameStatic were returning different strings.I am not changing the return type of GetPluginNameStatic in this patch, as thatwould necessitate additional changes, and this patch is big enough as it is.Differential Revision: https://reviews.llvm.org/D111877
[lldb] Remove PluginInterface::GetPluginVersionIn all these years, we haven't found a use for this function (it haszero callers). Lets just remove the boilerplate.Differential Revision: https://
[lldb] Remove PluginInterface::GetPluginVersionIn all these years, we haven't found a use for this function (it haszero callers). Lets just remove the boilerplate.Differential Revision: https://reviews.llvm.org/D109600
[NFC] Reordering parameters in getFile and getFileOrSTDINIn future patches I will be setting the IsText parameter frequently so I will refactor the args to be in the following order. I have removed
[NFC] Reordering parameters in getFile and getFileOrSTDINIn future patches I will be setting the IsText parameter frequently so I will refactor the args to be in the following order. I have removed the FileSize parameter because it is never used.``` static ErrorOr<std::unique_ptr<MemoryBuffer>> getFile(const Twine &Filename, bool IsText = false, bool RequiresNullTerminator = true, bool IsVolatile = false); static ErrorOr<std::unique_ptr<MemoryBuffer>> getFileOrSTDIN(const Twine &Filename, bool IsText = false, bool RequiresNullTerminator = true); static ErrorOr<std::unique_ptr<MB>> getFileAux(const Twine &Filename, uint64_t MapSize, uint64_t Offset, bool IsText, bool RequiresNullTerminator, bool IsVolatile); static ErrorOr<std::unique_ptr<WritableMemoryBuffer>> getFile(const Twine &Filename, bool IsVolatile = false);```Reviewed By: jhendersonDifferential Revision: https://reviews.llvm.org/D99182
[lldb][NFC] Refactor getUUID functionalityDifferential Revision: https://reviews.llvm.org/D90325
[lldb][PDB] Add ObjectFile PDB pluginTo allow loading PDB file with `target symbols add` command.Differential Revision: https://reviews.llvm.org/D89812