[lldb] Rename Logging.h to LLDBLog.h and clean up includesMost of our code was including Log.h even though that is not where the"lldb" log channel is defined (Log.h defines the generic logginginf
[lldb] Rename Logging.h to LLDBLog.h and clean up includesMost of our code was including Log.h even though that is not where the"lldb" log channel is defined (Log.h defines the generic logginginfrastructure). This worked because Log.h included Logging.h, eventhough it should.After the recent refactor, it became impossible the two files includeeach other in this direction (the opposite inclusion is needed), so thispatch removes the workaround that was put in place and cleans up allfiles to include the right thing. It also renames the file to LLDBLog tobetter reflect its purpose.
show more ...
[lldb] Convert "LLDB" log channel to the new API
Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.- It conflicts with the existing llvm::size in STLEx
Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.- It conflicts with the existing llvm::size in STLExtras, which will now never be called.- Calling it without llvm:: breaks C++17 compat
Rename llvm::array_lengthof into llvm::size to match std::size from C++17As a conquence move llvm::array_lengthof from STLExtras.h toSTLForwardCompat.h (which is included by STLExtras.h so no buil
Rename llvm::array_lengthof into llvm::size to match std::size from C++17As a conquence move llvm::array_lengthof from STLExtras.h toSTLForwardCompat.h (which is included by STLExtras.h so no buildbreakage expected).
[lldb] Remove ConstString from ABI, Architecture and Disassembler plugin names
[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
Recommit: [lldb] Remove "dwarf dynamic register size expressions" from RegisterInfoThe previous version of the patch did not update the definitions inconditionally compiled code. This patch includ
Recommit: [lldb] Remove "dwarf dynamic register size expressions" from RegisterInfoThe previous version of the patch did not update the definitions inconditionally compiled code. This patch includes changes to ARC andwindows targets.Original commit message was:These were added to support some mips registers on linux, but linux mipssupport has now been removed due.They are still referenced in the freebds mips implementation, but thecompleteness of that implementation is also unknown. All otherarchitectures just set these fields to zero, which is a cause ofsignificant bloat in our register info definitions.Arm also has registers with variable sizes, but they were implemented ina more gdb-compatible fashion and don't use this feature.Differential Revision: https://reviews.llvm.org/D110914
Revert "[lldb] Remove "dwarf dynamic register size expressions" from RegisterInfo"This reverts commit 00e704bf080ffeeb9e334fb3ab71594f9aa50969.This commit should should have updatedllvm/llvm-pro
Revert "[lldb] Remove "dwarf dynamic register size expressions" from RegisterInfo"This reverts commit 00e704bf080ffeeb9e334fb3ab71594f9aa50969.This commit should should have updatedllvm/llvm-project/lldb/source/Plugins/ABI/ARC/ABISysV_arc.cpp like the otherarchitectures.
[lldb] Remove "dwarf dynamic register size expressions" from RegisterInfoThese were added to support some mips registers on linux, but linux mipssupport has now been removed due.They are still r
[lldb] Remove "dwarf dynamic register size expressions" from RegisterInfoThese were added to support some mips registers on linux, but linux mipssupport has now been removed due.They are still referenced in the freebds mips implementation, but thecompleteness of that implementation is also unknown. All otherarchitectures just set these fields to zero, which is a cause ofsignificant bloat in our register info definitions.Arm also has registers with variable sizes, but they were implemented ina more gdb-compatible fashion and don't use this feature.Differential Revision: https://reviews.llvm.org/D110914
[lldb] Remove redundant register alt_namesRemove redundant register alt_names that correspond to their respectivegeneric names. D108554 makes it possible to query registers throughtheir generic
[lldb] Remove redundant register alt_namesRemove redundant register alt_names that correspond to their respectivegeneric names. D108554 makes it possible to query registers throughtheir generic names directly, therefore making repeating them viaalt_name unnecessary.While at it, also remove alt_names that are equal to register nameson PPC.This patch does not alter register definitions where the generic namesare listed as primary names, and other names are provided as alt_name(e.g. ARM).Differential Revision: https://reviews.llvm.org/D109626
[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
[lldb] Fix up SysV ABI implementations after 057efa9916cdc354ef4653bcd128a578cc43125e
[lldb] Remove all the RegisterInfo name constification codeRegisterInfo's `reg_name`/`reg_alt_name` fields are C-Strings and are supposedto only be generated from a ConstString. The reason for tha
[lldb] Remove all the RegisterInfo name constification codeRegisterInfo's `reg_name`/`reg_alt_name` fields are C-Strings and are supposedto only be generated from a ConstString. The reason for that is that`DynamicRegisterInfo::GetRegisterInfo` and`RegInfoBasedABI::GetRegisterInfoByName` try to optimise finding registers byname by only comparing the C string pointer values instead of the underlyingstrings. This only works if both C strings involved in the comparison come froma ConstString. If one of the two C strings doesn't come from a ConstString thecomparison won't work (and most likely will silently fail).I added an assert in b0060c3a7868ef026d95d0cf8a076791ef74f474 which checks thatboth strings come from a ConstString. Apparently not all ABI plugins aregenerating their register names via ConstString, so this code is now not justsilently failing but also asserting.In D88375 we did a shady fix for the MIPS plugins by just copying theConstString setup code to that plugin, but we still need to fix ABISysV_arc,ABISysV_ppc and ABISysV_ppc64 plugins.I would say we just fix the remaining plugins by removing the whole requirementto have the register names coming from ConstStrings. I really doubt that weactually save any time with the whole ConstString search trick (searching ~50strings that have <4 characters doesn't sound more expensive than calling thereally expensive ConstString constructor + comparing the same amount of pointervalues). Also whatever small percentage of LLDB's runtime is actually spend inthis function is anyway not worth the complexity of this approach.This patch just removes all this and just does a normal string comparison.Reviewed By: JDevlieghere, labathDifferential Revision: https://reviews.llvm.org/D88490
Thread ExecutionContextScope through GetByteSize where possible (NFC-ish)This patch has no effect for C and C++. In more dynamic languages,such as Objective-C and Swift GetByteSize() needs to call
Thread ExecutionContextScope through GetByteSize where possible (NFC-ish)This patch has no effect for C and C++. In more dynamic languages,such as Objective-C and Swift GetByteSize() needs to call into thelanguage runtime, so it's important to pass one in where possible. Myprimary motivation for this is some work I'm doing on the Swiftbranch, however, it looks like we are also seeing warnings inObjective-C that this may resolve. Everything in the SymbolFilehierarchy still passes in nullptrs, because we don't have an executioncontext in SymbolFile, since SymbolFile transcends processes.Differential Revision: https://reviews.llvm.org/D84267
[lldb] Update header guards to be consistent and compliant with LLVM (NFC)LLDB has a few different styles of header guards and they're not veryconsistent because things get moved around or copy/pa
[lldb] Update header guards to be consistent and compliant with LLVM (NFC)LLDB has a few different styles of header guards and they're not veryconsistent because things get moved around or copy/pasted. This patchunifies the header guards across LLDB and converts everything to matchLLVM's style.Differential revision: https://reviews.llvm.org/D74743
[lldb/Plugins] Initialize all ABI plugins by their plugin name
Revert "[lldb/CMake] Auto-generate the Initialize and Terminate calls for plugin"This is still failing spectacularly on the Windows bot and I still haveno clue what's going on.
Re-land "[lldb/CMake] Auto-generate the Initialize and Terminate calls for plugin"This patch changes the way we initialize and terminate the plugins inthe system initializer. It uses an approach s
Re-land "[lldb/CMake] Auto-generate the Initialize and Terminate calls for plugin"This patch changes the way we initialize and terminate the plugins inthe system initializer. It uses an approach similar to LLVM'sTARGETS_TO_BUILD with a def file that enumerates the plugins.The previously landed patch got reverted because it was lacking: (1) A plugin definition for the Objective-C language runtime, (2) The dependency between the Static and WASM dynamic loader, (3) Explicit initialization of ScriptInterpreterNone for lldb-test.All issues have been addressed in this patch.Differential revision: https://reviews.llvm.org/D73067
Revert "[lldb/CMake] Auto-generate the Initialize and Terminate calls for plugin"This temporarily reverts commit 7d6da329dee1eda1761430d9097d1323f32c4c0cbecause it's causing test failures on the b
Revert "[lldb/CMake] Auto-generate the Initialize and Terminate calls for plugin"This temporarily reverts commit 7d6da329dee1eda1761430d9097d1323f32c4c0cbecause it's causing test failures on the bots.
[lldb/CMake] Auto-generate the Initialize and Terminate calls for pluginThis patch changes the way we initialize and terminate the plugins inthe system initializer. It uses an approach similar to
[lldb/CMake] Auto-generate the Initialize and Terminate calls for pluginThis patch changes the way we initialize and terminate the plugins inthe system initializer. It uses an approach similar to LLVM'sTARGETS_TO_BUILD with a def file that enumerates the plugins.Differential revision: https://reviews.llvm.org/D73067
[lldb/Plugin] s/LLDB_PLUGIN/LLDB_PLUGIN_DEFINE/ (NFC)Rename LLDB_PLUGIN to LLDB_PLUGIN_DEFINE as Pavel suggested in D73067 toavoid name conflict.
[lldb] Introduce "RegInfoBasedABI"Summary:This patch creates a new subclass of the ABI class in order to abstract away themechanism in which we "augment" register information. This enables altern
[lldb] Introduce "RegInfoBasedABI"Summary:This patch creates a new subclass of the ABI class in order to abstract away themechanism in which we "augment" register information. This enables alternateaugmentation strategies to be introduced.All existing ABI classes have been modified to inherit from RegInfoBasedABI, butthey will be refactored in subsequent patches.Reviewers: JDevlieghere, jasonmolendaSubscribers: sdardis, nemanjai, kbarton, jrtc27, atanasyan, jsji, lldb-commitsTags: #lldbDifferential Revision: https://reviews.llvm.org/D74243
[LLDB] Fix GCC warnings about extra semicolons. NFC.
[lldb/Plugins] Use external functions to (de)initialize pluginsThis is a step towards making the initialize and terminate calls begenerated by CMake, which in turn is towards making it possible to
[lldb/Plugins] Use external functions to (de)initialize pluginsThis is a step towards making the initialize and terminate calls begenerated by CMake, which in turn is towards making it possible todisable plugins at configuration time.Differential revision: https://reviews.llvm.org/D74245
[lldb] Group ABI pluginsSummary:There's a fair amount of code duplication between the different ABI plugins forthe same architecture (e.g. ABIMacOSX_arm & ABISysV_arm). Deduplicating thiscode is
[lldb] Group ABI pluginsSummary:There's a fair amount of code duplication between the different ABI plugins forthe same architecture (e.g. ABIMacOSX_arm & ABISysV_arm). Deduplicating thiscode is not very easy at the moment because there is no good place where to putthe common code.Instead of creating more plugins, this patch reduces their number by groupingsimilar plugins into a single folder/plugin. This makes it easy to extractcommon code to a (e.g.) base class, which can then live in the same folder.The grouping is done based on the underlying llvm target for that architecture,because the plugins already require this for their operation.Reviewers: JDevlieghere, jasonmolenda, jfbSubscribers: sdardis, nemanjai, mgorny, kristof.beyls, fedor.sergeev, kbarton, jrtc27, atanasyan, jsji, lldb-commitsTags: #lldbDifferential Revision: https://reviews.llvm.org/D74138