maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/Target/ABI.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

274 lines
9.0 KiB
C++
Raw Normal View History

[lldb][NFC] Fix all formatting errors in .cpp file headers Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 15:23:27 +08:00
//===-- ABI.cpp -----------------------------------------------------------===//
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//
//===----------------------------------------------------------------------===//
#include "lldb/Target/ABI.h"
#include "lldb/Core/PluginManager.h"
Add the ability to capture the return value in a thread's stop info, and print it as part of the thread format output. Currently this is only done for the ThreadPlanStepOut. Add a convenience API ABI::GetReturnValueObject. Change the ValueObject::EvaluationPoint to BE an ExecutionContextScope, rather than trying to hand out one of its subsidiary object's pointers. That way this will always be good. llvm-svn: 146806
2011-12-17 09:35:57 +08:00
#include "lldb/Core/Value.h"
#include "lldb/Core/ValueObjectConstResult.h"
[Target] Remove ABI's dependence on ExpressionParser llvm-svn: 362259
2019-06-01 04:17:21 +08:00
#include "lldb/Expression/ExpressionVariable.h"
ClangASTType is now CompilerType. This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc). llvm-svn: 244689
2015-08-12 06:53:00 +08:00
#include "lldb/Symbol/CompilerType.h"
Now persistent expression data no longer lives with the Target, but rather with the corresponding TypeSystem. This makes sense because what kind of data there is -- and how it can be looked up -- depends on the language. Functionality that is common to all type systems is factored out into PersistentExpressionState. llvm-svn: 248934
2015-10-01 03:57:57 +08:00
#include "lldb/Symbol/TypeSystem.h"
Improve the x86_64 return value decoder to handle most structure returns. Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject which is much more convenient. Return the "return value object" as a persistent variable if requested. llvm-svn: 147157
2011-12-23 03:12:40 +08:00
#include "lldb/Target/Target.h"
Add the ability to capture the return value in a thread's stop info, and print it as part of the thread format output. Currently this is only done for the ThreadPlanStepOut. Add a convenience API ABI::GetReturnValueObject. Change the ValueObject::EvaluationPoint to BE an ExecutionContextScope, rather than trying to hand out one of its subsidiary object's pointers. That way this will always be good. llvm-svn: 146806
2011-12-17 09:35:57 +08:00
#include "lldb/Target/Thread.h"
Have ABI plugins vend llvm MCRegisterInfo data Summary: I was recently surprised to learn that there is a total of 2 (two) users of the register info definitions contained in the ABI plugins. Yet, the defitions themselves span nearly 10kLOC. The two users are: - dwarf expression pretty printer - the mechanism for augmenting the register info definitions obtained over gdb-remote protocol (AugmentRegisterInfoViaABI) Both of these uses need the DWARF an EH register numbers, which is information that is already available in LLVM. This patch makes it possible to do so. It adds a GetMCRegisterInfo method to the ABI class, which every class is expected to implement. Normally, it should be sufficient to obtain the definitions from the appropriate llvm::Target object (for which I provide a utility function), but the subclasses are free to construct it in any way they deem fit. We should be able to always get the MCRegisterInfo object from llvm, with one important exception: if the relevant llvm target was disabled at compile time. To handle this, I add a mechanism to disable the compilation of ABI plugins based on the value of LLVM_TARGETS_TO_BUILD cmake setting. This ensures all our existing are able to create their MCRegisterInfo objects. The new MCRegisterInfo api is not used yet, but the intention is to make use of it in follow-up patches. Reviewers: jasonmolenda, aprantl, JDevlieghere, tatyana-krasnukha Subscribers: wuzish, nemanjai, mgorny, kbarton, atanasyan, lldb-commits Differential Revision: https://reviews.llvm.org/D67965 llvm-svn: 372862
2019-09-25 21:03:04 +08:00
#include "lldb/Utility/Log.h"
Move TargetRegistry.(h|cpp) from Support to MC This moves the registry higher in the LLVM library dependency stack. Every client of the target registry needs to link against MC anyway to actually use the target, so we might as well move this out of Support. This allows us to ensure that Support doesn't have includes from MC/*. Differential Revision: https://reviews.llvm.org/D111454
2021-10-09 01:48:15 +08:00
#include "llvm/MC/TargetRegistry.h"
[lldb] Fix Windows bot. Should fix error C2039: 'toupper': is not a member of 'std'.
2020-02-18 01:06:18 +08:00
#include <cctype>
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
using namespace lldb;
using namespace lldb_private;
Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into their respective ABI plugins as they were plug-ins that supplied ABI specfic info. Also hookep up the UnwindAssemblyInstEmulation so that it can generate the unwind plans for ARM. Changed the way ABI plug-ins are handed out when you get an instance from the plug-in manager. They used to return pointers that would be mananged individually by each client that requested them, but now they are handed out as shared pointers since there is no state in the ABI objects, they can be shared. llvm-svn: 131193
2011-05-12 02:39:18 +08:00
ABISP
Change the ABI class to have a weak pointer to its Process; some methods in the ABI need a Process to do their work. Instead of passing it in as a one-off argument to those methods, this patch puts it in the base class and the methods can retrieve if it needed. Note that ABI's are sometimes built without a Process (e.g. SBTarget::GetStackRedZoneSize) so it's entirely possible that the process weak pointer will not be able to reconsistitue into a strong pointer. <rdar://problem/32526754> llvm-svn: 306633
2017-06-29 10:57:03 +08:00
ABI::FindPlugin(lldb::ProcessSP process_sp, const ArchSpec &arch) {
Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into their respective ABI plugins as they were plug-ins that supplied ABI specfic info. Also hookep up the UnwindAssemblyInstEmulation so that it can generate the unwind plans for ARM. Changed the way ABI plug-ins are handed out when you get an instance from the plug-in manager. They used to return pointers that would be mananged individually by each client that requested them, but now they are handed out as shared pointers since there is no state in the ABI objects, they can be shared. llvm-svn: 131193
2011-05-12 02:39:18 +08:00
ABISP abi_sp;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
ABICreateInstance create_callback;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
for (uint32_t idx = 0;
Fix Clang-tidy modernize-use-nullptr warnings; other minor fixes. llvm-svn: 261179
2016-02-18 08:10:17 +08:00
(create_callback = PluginManager::GetABICreateCallbackAtIndex(idx)) !=
nullptr;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
++idx) {
Change the ABI class to have a weak pointer to its Process; some methods in the ABI need a Process to do their work. Instead of passing it in as a one-off argument to those methods, this patch puts it in the base class and the methods can retrieve if it needed. Note that ABI's are sometimes built without a Process (e.g. SBTarget::GetStackRedZoneSize) so it's entirely possible that the process weak pointer will not be able to reconsistitue into a strong pointer. <rdar://problem/32526754> llvm-svn: 306633
2017-06-29 10:57:03 +08:00
abi_sp = create_callback(process_sp, arch);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into their respective ABI plugins as they were plug-ins that supplied ABI specfic info. Also hookep up the UnwindAssemblyInstEmulation so that it can generate the unwind plans for ARM. Changed the way ABI plug-ins are handed out when you get an instance from the plug-in manager. They used to return pointers that would be mananged individually by each client that requested them, but now they are handed out as shared pointers since there is no state in the ABI objects, they can be shared. llvm-svn: 131193
2011-05-12 02:39:18 +08:00
if (abi_sp)
return abi_sp;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into their respective ABI plugins as they were plug-ins that supplied ABI specfic info. Also hookep up the UnwindAssemblyInstEmulation so that it can generate the unwind plans for ARM. Changed the way ABI plug-ins are handed out when you get an instance from the plug-in manager. They used to return pointers that would be mananged individually by each client that requested them, but now they are handed out as shared pointers since there is no state in the ABI objects, they can be shared. llvm-svn: 131193
2011-05-12 02:39:18 +08:00
abi_sp.reset();
return abi_sp;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Fix Clang-tidy modernize-use-nullptr warnings; other minor fixes. llvm-svn: 261179
2016-02-18 08:10:17 +08:00
ABI::~ABI() = default;
Added a new plug-in type: lldb_private::OperatingSystem. The operating system plug-ins are add on plug-ins for the lldb_private::Process class that can add thread contexts that are read from memory. It is common in kernels to have a lot of threads that are not currently executing on any cores (JTAG debugging also follows this sort of thing) and are context switched out whose state is stored in memory data structures. Clients can now subclass the OperatingSystem plug-ins and then make sure their Create functions correcltly only enable themselves when the right binary/target triple are being debugged. The operating system plug-ins get a chance to attach themselves to processes just after launching or attaching and are given a lldb_private::Process object pointer which can be inspected to see if the main executable, target triple, or any shared libraries match a case where the OS plug-in should be used. Currently the OS plug-ins can create new threads, define the register contexts for these threads (which can all be different if desired), and populate and manage the thread info (stop reason, registers in the register context) as the debug session goes on. llvm-svn: 138228
2011-08-22 10:49:39 +08:00
[lldb] Remove all the RegisterInfo name constification code RegisterInfo's `reg_name`/`reg_alt_name` fields are C-Strings and are supposed to only be generated from a ConstString. The reason for that is that `DynamicRegisterInfo::GetRegisterInfo` and `RegInfoBasedABI::GetRegisterInfoByName` try to optimise finding registers by name by only comparing the C string pointer values instead of the underlying strings. This only works if both C strings involved in the comparison come from a ConstString. If one of the two C strings doesn't come from a ConstString the comparison won't work (and most likely will silently fail). I added an assert in b0060c3a7868ef026d95d0cf8a076791ef74f474 which checks that both strings come from a ConstString. Apparently not all ABI plugins are generating their register names via ConstString, so this code is now not just silently failing but also asserting. In D88375 we did a shady fix for the MIPS plugins by just copying the ConstString 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 requirement to have the register names coming from ConstStrings. I really doubt that we actually save any time with the whole ConstString search trick (searching ~50 strings that have <4 characters doesn't sound more expensive than calling the really expensive ConstString constructor + comparing the same amount of pointer values). Also whatever small percentage of LLDB's runtime is actually spend in this 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, labath Differential Revision: https://reviews.llvm.org/D88490
2020-10-13 23:10:10 +08:00
bool RegInfoBasedABI::GetRegisterInfoByName(llvm::StringRef name,
RegisterInfo &info) {
Added a new plug-in type: lldb_private::OperatingSystem. The operating system plug-ins are add on plug-ins for the lldb_private::Process class that can add thread contexts that are read from memory. It is common in kernels to have a lot of threads that are not currently executing on any cores (JTAG debugging also follows this sort of thing) and are context switched out whose state is stored in memory data structures. Clients can now subclass the OperatingSystem plug-ins and then make sure their Create functions correcltly only enable themselves when the right binary/target triple are being debugged. The operating system plug-ins get a chance to attach themselves to processes just after launching or attaching and are given a lldb_private::Process object pointer which can be inspected to see if the main executable, target triple, or any shared libraries match a case where the OS plug-in should be used. Currently the OS plug-ins can create new threads, define the register contexts for these threads (which can all be different if desired), and populate and manage the thread info (stop reason, registers in the register context) as the debug session goes on. llvm-svn: 138228
2011-08-22 10:49:39 +08:00
uint32_t count = 0;
const RegisterInfo *register_info_array = GetRegisterInfoArray(count);
if (register_info_array) {
uint32_t i;
Fix Clang-tidy modernize-use-nullptr warnings; other minor fixes. llvm-svn: 261179
2016-02-18 08:10:17 +08:00
for (i = 0; i < count; ++i) {
[lldb] Make comparing RegisterInfo::[alt_]name's pointer value less footy-shooty Comparing those two `const char *` values relies on the assumption that both strings were created by a ConstString. Let's check that assumption with an assert as otherwise this code silently does nothing and that's not great.
2020-02-19 18:27:10 +08:00
const char *reg_name = register_info_array[i].name;
[lldb] Remove all the RegisterInfo name constification code RegisterInfo's `reg_name`/`reg_alt_name` fields are C-Strings and are supposed to only be generated from a ConstString. The reason for that is that `DynamicRegisterInfo::GetRegisterInfo` and `RegInfoBasedABI::GetRegisterInfoByName` try to optimise finding registers by name by only comparing the C string pointer values instead of the underlying strings. This only works if both C strings involved in the comparison come from a ConstString. If one of the two C strings doesn't come from a ConstString the comparison won't work (and most likely will silently fail). I added an assert in b0060c3a7868ef026d95d0cf8a076791ef74f474 which checks that both strings come from a ConstString. Apparently not all ABI plugins are generating their register names via ConstString, so this code is now not just silently failing but also asserting. In D88375 we did a shady fix for the MIPS plugins by just copying the ConstString 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 requirement to have the register names coming from ConstStrings. I really doubt that we actually save any time with the whole ConstString search trick (searching ~50 strings that have <4 characters doesn't sound more expensive than calling the really expensive ConstString constructor + comparing the same amount of pointer values). Also whatever small percentage of LLDB's runtime is actually spend in this 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, labath Differential Revision: https://reviews.llvm.org/D88490
2020-10-13 23:10:10 +08:00
if (reg_name == name) {
Added a new plug-in type: lldb_private::OperatingSystem. The operating system plug-ins are add on plug-ins for the lldb_private::Process class that can add thread contexts that are read from memory. It is common in kernels to have a lot of threads that are not currently executing on any cores (JTAG debugging also follows this sort of thing) and are context switched out whose state is stored in memory data structures. Clients can now subclass the OperatingSystem plug-ins and then make sure their Create functions correcltly only enable themselves when the right binary/target triple are being debugged. The operating system plug-ins get a chance to attach themselves to processes just after launching or attaching and are given a lldb_private::Process object pointer which can be inspected to see if the main executable, target triple, or any shared libraries match a case where the OS plug-in should be used. Currently the OS plug-ins can create new threads, define the register contexts for these threads (which can all be different if desired), and populate and manage the thread info (stop reason, registers in the register context) as the debug session goes on. llvm-svn: 138228
2011-08-22 10:49:39 +08:00
info = register_info_array[i];
return true;
}
}
Fix Clang-tidy modernize-use-nullptr warnings; other minor fixes. llvm-svn: 261179
2016-02-18 08:10:17 +08:00
for (i = 0; i < count; ++i) {
[lldb] Make comparing RegisterInfo::[alt_]name's pointer value less footy-shooty Comparing those two `const char *` values relies on the assumption that both strings were created by a ConstString. Let's check that assumption with an assert as otherwise this code silently does nothing and that's not great.
2020-02-19 18:27:10 +08:00
const char *reg_alt_name = register_info_array[i].alt_name;
[lldb] Remove all the RegisterInfo name constification code RegisterInfo's `reg_name`/`reg_alt_name` fields are C-Strings and are supposed to only be generated from a ConstString. The reason for that is that `DynamicRegisterInfo::GetRegisterInfo` and `RegInfoBasedABI::GetRegisterInfoByName` try to optimise finding registers by name by only comparing the C string pointer values instead of the underlying strings. This only works if both C strings involved in the comparison come from a ConstString. If one of the two C strings doesn't come from a ConstString the comparison won't work (and most likely will silently fail). I added an assert in b0060c3a7868ef026d95d0cf8a076791ef74f474 which checks that both strings come from a ConstString. Apparently not all ABI plugins are generating their register names via ConstString, so this code is now not just silently failing but also asserting. In D88375 we did a shady fix for the MIPS plugins by just copying the ConstString 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 requirement to have the register names coming from ConstStrings. I really doubt that we actually save any time with the whole ConstString search trick (searching ~50 strings that have <4 characters doesn't sound more expensive than calling the really expensive ConstString constructor + comparing the same amount of pointer values). Also whatever small percentage of LLDB's runtime is actually spend in this 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, labath Differential Revision: https://reviews.llvm.org/D88490
2020-10-13 23:10:10 +08:00
if (reg_alt_name == name) {
Added a new plug-in type: lldb_private::OperatingSystem. The operating system plug-ins are add on plug-ins for the lldb_private::Process class that can add thread contexts that are read from memory. It is common in kernels to have a lot of threads that are not currently executing on any cores (JTAG debugging also follows this sort of thing) and are context switched out whose state is stored in memory data structures. Clients can now subclass the OperatingSystem plug-ins and then make sure their Create functions correcltly only enable themselves when the right binary/target triple are being debugged. The operating system plug-ins get a chance to attach themselves to processes just after launching or attaching and are given a lldb_private::Process object pointer which can be inspected to see if the main executable, target triple, or any shared libraries match a case where the OS plug-in should be used. Currently the OS plug-ins can create new threads, define the register contexts for these threads (which can all be different if desired), and populate and manage the thread info (stop reason, registers in the register context) as the debug session goes on. llvm-svn: 138228
2011-08-22 10:49:39 +08:00
info = register_info_array[i];
return true;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
}
}
Added a new plug-in type: lldb_private::OperatingSystem. The operating system plug-ins are add on plug-ins for the lldb_private::Process class that can add thread contexts that are read from memory. It is common in kernels to have a lot of threads that are not currently executing on any cores (JTAG debugging also follows this sort of thing) and are context switched out whose state is stored in memory data structures. Clients can now subclass the OperatingSystem plug-ins and then make sure their Create functions correcltly only enable themselves when the right binary/target triple are being debugged. The operating system plug-ins get a chance to attach themselves to processes just after launching or attaching and are given a lldb_private::Process object pointer which can be inspected to see if the main executable, target triple, or any shared libraries match a case where the OS plug-in should be used. Currently the OS plug-ins can create new threads, define the register contexts for these threads (which can all be different if desired), and populate and manage the thread info (stop reason, registers in the register context) as the debug session goes on. llvm-svn: 138228
2011-08-22 10:49:39 +08:00
return false;
}
ABI for the Hexagon DSP llvm-svn: 213566
2014-07-22 01:21:01 +08:00
ValueObjectSP ABI::GetReturnValueObject(Thread &thread, CompilerType &ast_type,
bool persistent) const {
Add the ability to capture the return value in a thread's stop info, and print it as part of the thread format output. Currently this is only done for the ThreadPlanStepOut. Add a convenience API ABI::GetReturnValueObject. Change the ValueObject::EvaluationPoint to BE an ExecutionContextScope, rather than trying to hand out one of its subsidiary object's pointers. That way this will always be good. llvm-svn: 146806
2011-12-17 09:35:57 +08:00
if (!ast_type.IsValid())
return ValueObjectSP();
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
ABI for the Hexagon DSP llvm-svn: 213566
2014-07-22 01:21:01 +08:00
ValueObjectSP return_valobj_sp;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
ABI for the Hexagon DSP llvm-svn: 213566
2014-07-22 01:21:01 +08:00
return_valobj_sp = GetReturnValueObjectImpl(thread, ast_type);
Improve the x86_64 return value decoder to handle most structure returns. Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject which is much more convenient. Return the "return value object" as a persistent variable if requested. llvm-svn: 147157
2011-12-23 03:12:40 +08:00
if (!return_valobj_sp)
ABI for the Hexagon DSP llvm-svn: 213566
2014-07-22 01:21:01 +08:00
return return_valobj_sp;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Improve the x86_64 return value decoder to handle most structure returns. Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject which is much more convenient. Return the "return value object" as a persistent variable if requested. llvm-svn: 147157
2011-12-23 03:12:40 +08:00
// Now turn this into a persistent variable.
// FIXME: This code is duplicated from Target::EvaluateExpression, and it is
// used in similar form in a couple
// of other places. Figure out the correct Create function to do all this
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
// work.
Improve the x86_64 return value decoder to handle most structure returns. Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject which is much more convenient. Return the "return value object" as a persistent variable if requested. llvm-svn: 147157
2011-12-23 03:12:40 +08:00
if (persistent) {
Move the persistent variable counter into Target so it can be shared across multiple language plugins. In a multi-language project it is counterintuitive to have a result variables reuse numbers just because they are using a different language plugin in LLDB (but not for example, when they are Objective-C versus C++, since they are both handled by Clang). This is NFC on llvm.org except for the Go plugin. rdar://problem/39299889 Differential Revision: https://reviews.llvm.org/D46083 llvm-svn: 331234
2018-05-01 07:59:15 +08:00
Target &target = *thread.CalculateTarget();
Made Target hold a map of languages to TypeSystems, and added some accessors. Also added some target-level search functions so that persistent variables and symbols can be searched for without hand-iterating across the map of TypeSystems. llvm-svn: 249027
2015-10-02 00:28:02 +08:00
PersistentExpressionState *persistent_expression_state =
Move the persistent variable counter into Target so it can be shared across multiple language plugins. In a multi-language project it is counterintuitive to have a result variables reuse numbers just because they are using a different language plugin in LLDB (but not for example, when they are Objective-C versus C++, since they are both handled by Clang). This is NFC on llvm.org except for the Go plugin. rdar://problem/39299889 Differential Revision: https://reviews.llvm.org/D46083 llvm-svn: 331234
2018-05-01 07:59:15 +08:00
target.GetPersistentExpressionStateForLanguage(
Made Target hold a map of languages to TypeSystems, and added some accessors. Also added some target-level search functions so that persistent variables and symbols can be searched for without hand-iterating across the map of TypeSystems. llvm-svn: 249027
2015-10-02 00:28:02 +08:00
ast_type.GetMinimumLanguage());
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Now persistent expression data no longer lives with the Target, but rather with the corresponding TypeSystem. This makes sense because what kind of data there is -- and how it can be looked up -- depends on the language. Functionality that is common to all type systems is factored out into PersistentExpressionState. llvm-svn: 248934
2015-10-01 03:57:57 +08:00
if (!persistent_expression_state)
Add missing nullptr checks. GetPersistentExpressionStateForLanguage() can return a nullptr if it cannot construct a typesystem. This patch adds missing nullptr checks at all uses. Inspired by rdar://problem/58317195 Differential Revision: https://reviews.llvm.org/D72413
2020-01-09 06:18:47 +08:00
return {};
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Refactor GetNextPersistentVariableName into a non-virtual method that takes a prefix string. This simplifies the implementation and allows plugins such as the Swift plugin to supply different prefixes for return and error variables. rdar://problem/39299889 Differential Revision: https://reviews.llvm.org/D46088 llvm-svn: 331235
2018-05-01 07:59:17 +08:00
ConstString persistent_variable_name =
Internal expressions shouldn't increment the result variable numbering. There an option: EvaluateExpressionOptions::SetResultIsInternal to indicate whether the result number should be returned to the pool or not. It got broken when the PersistentExpressionState was refactored. This fixes the issue and provides a test of the behavior. Differential Revision: https://reviews.llvm.org/D76532
2020-03-21 05:59:54 +08:00
persistent_expression_state->GetNextPersistentVariableName();
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Improve the x86_64 return value decoder to handle most structure returns. Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject which is much more convenient. Return the "return value object" as a persistent variable if requested. llvm-svn: 147157
2011-12-23 03:12:40 +08:00
lldb::ValueObjectSP const_valobj_sp;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Improve the x86_64 return value decoder to handle most structure returns. Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject which is much more convenient. Return the "return value object" as a persistent variable if requested. llvm-svn: 147157
2011-12-23 03:12:40 +08:00
// Check in case our value is already a constant value
if (return_valobj_sp->GetIsConstant()) {
const_valobj_sp = return_valobj_sp;
const_valobj_sp->SetName(persistent_variable_name);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
} else
Improve the x86_64 return value decoder to handle most structure returns. Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject which is much more convenient. Return the "return value object" as a persistent variable if requested. llvm-svn: 147157
2011-12-23 03:12:40 +08:00
const_valobj_sp =
return_valobj_sp->CreateConstantValue(persistent_variable_name);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Improve the x86_64 return value decoder to handle most structure returns. Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject which is much more convenient. Return the "return value object" as a persistent variable if requested. llvm-svn: 147157
2011-12-23 03:12:40 +08:00
lldb::ValueObjectSP live_valobj_sp = return_valobj_sp;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Improve the x86_64 return value decoder to handle most structure returns. Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject which is much more convenient. Return the "return value object" as a persistent variable if requested. llvm-svn: 147157
2011-12-23 03:12:40 +08:00
return_valobj_sp = const_valobj_sp;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
[Target][NFCI] Rename variable This variable doesn't have anything to do with clang. llvm-svn: 366292
2019-07-17 15:03:17 +08:00
ExpressionVariableSP expr_variable_sp(
Eliminated redundant "constructors" for ClangExpressionVariable. The ClangExpressionVariable::CreateVariableInList functions looked cute, but caused more confusion than they solved. I removed them, and instead made sure that there are adequate facilities for easily adding newly-constructed ExpressionVariables to lists. I also made some of the constructors that are common be generic, so that it's possible to construct expression variables from generic places (like the ABI and ValueObject) without having to know the specifics about the class. llvm-svn: 249095
2015-10-02 07:07:06 +08:00
persistent_expression_state->CreatePersistentVariable(
return_valobj_sp));
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
[Target][NFCI] Rename variable This variable doesn't have anything to do with clang. llvm-svn: 366292
2019-07-17 15:03:17 +08:00
assert(expr_variable_sp);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Improve the x86_64 return value decoder to handle most structure returns. Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject which is much more convenient. Return the "return value object" as a persistent variable if requested. llvm-svn: 147157
2011-12-23 03:12:40 +08:00
// Set flags and live data as appropriate
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Improve the x86_64 return value decoder to handle most structure returns. Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject which is much more convenient. Return the "return value object" as a persistent variable if requested. llvm-svn: 147157
2011-12-23 03:12:40 +08:00
const Value &result_value = live_valobj_sp->GetValue();
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Improve the x86_64 return value decoder to handle most structure returns. Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject which is much more convenient. Return the "return value object" as a persistent variable if requested. llvm-svn: 147157
2011-12-23 03:12:40 +08:00
switch (result_value.GetValueType()) {
Make the error condition in Value::ValueType explicit (NFC) The comment for ValueType claims that all values <1 are errors, but not all switch statements take this into account. This patch introduces an explicit Error case and deletes all default: cases, so we get warned about incomplete switch coverage. https://reviews.llvm.org/D96537
2021-02-12 04:57:04 +08:00
case Value::ValueType::Invalid:
return {};
case Value::ValueType::HostAddress:
case Value::ValueType::FileAddress:
// we odon't do anything with these for now
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
break;
Make the error condition in Value::ValueType explicit (NFC) The comment for ValueType claims that all values <1 are errors, but not all switch statements take this into account. This patch introduces an explicit Error case and deletes all default: cases, so we get warned about incomplete switch coverage. https://reviews.llvm.org/D96537
2021-02-12 04:57:04 +08:00
case Value::ValueType::Scalar:
[Target][NFCI] Rename variable This variable doesn't have anything to do with clang. llvm-svn: 366292
2019-07-17 15:03:17 +08:00
expr_variable_sp->m_flags |=
[Target] Remove ABI's dependence on ExpressionParser llvm-svn: 362259
2019-06-01 04:17:21 +08:00
ExpressionVariable::EVIsFreezeDried;
[Target][NFCI] Rename variable This variable doesn't have anything to do with clang. llvm-svn: 366292
2019-07-17 15:03:17 +08:00
expr_variable_sp->m_flags |=
[Target] Remove ABI's dependence on ExpressionParser llvm-svn: 362259
2019-06-01 04:17:21 +08:00
ExpressionVariable::EVIsLLDBAllocated;
[Target][NFCI] Rename variable This variable doesn't have anything to do with clang. llvm-svn: 366292
2019-07-17 15:03:17 +08:00
expr_variable_sp->m_flags |=
[Target] Remove ABI's dependence on ExpressionParser llvm-svn: 362259
2019-06-01 04:17:21 +08:00
ExpressionVariable::EVNeedsAllocation;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
break;
Make the error condition in Value::ValueType explicit (NFC) The comment for ValueType claims that all values <1 are errors, but not all switch statements take this into account. This patch introduces an explicit Error case and deletes all default: cases, so we get warned about incomplete switch coverage. https://reviews.llvm.org/D96537
2021-02-12 04:57:04 +08:00
case Value::ValueType::LoadAddress:
[Target][NFCI] Rename variable This variable doesn't have anything to do with clang. llvm-svn: 366292
2019-07-17 15:03:17 +08:00
expr_variable_sp->m_live_sp = live_valobj_sp;
expr_variable_sp->m_flags |=
[Target] Remove ABI's dependence on ExpressionParser llvm-svn: 362259
2019-06-01 04:17:21 +08:00
ExpressionVariable::EVIsProgramReference;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
break;
}
[Target][NFCI] Rename variable This variable doesn't have anything to do with clang. llvm-svn: 366292
2019-07-17 15:03:17 +08:00
return_valobj_sp = expr_variable_sp->GetValueObject();
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
ABI for the Hexagon DSP llvm-svn: 213566
2014-07-22 01:21:01 +08:00
return return_valobj_sp;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
ABI for the Hexagon DSP llvm-svn: 213566
2014-07-22 01:21:01 +08:00
ValueObjectSP ABI::GetReturnValueObject(Thread &thread, llvm::Type &ast_type,
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
2012-02-21 08:09:25 +08:00
bool persistent) const {
ABI for the Hexagon DSP llvm-svn: 213566
2014-07-22 01:21:01 +08:00
ValueObjectSP return_valobj_sp;
Improve the x86_64 return value decoder to handle most structure returns. Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject which is much more convenient. Return the "return value object" as a persistent variable if requested. llvm-svn: 147157
2011-12-23 03:12:40 +08:00
return_valobj_sp = GetReturnValueObjectImpl(thread, ast_type);
ABI for the Hexagon DSP llvm-svn: 213566
2014-07-22 01:21:01 +08:00
return return_valobj_sp;
}
// specialized to work with llvm IR types
//
// for now we will specify a default implementation so that we don't need to
// modify other ABIs
lldb::ValueObjectSP ABI::GetReturnValueObjectImpl(Thread &thread,
llvm::Type &ir_type) const {
ValueObjectSP return_valobj_sp;
/* this is a dummy and will only be called if an ABI does not override this */
return return_valobj_sp;
}
Add the ability to capture the return value in a thread's stop info, and print it as part of the thread format output. Currently this is only done for the ThreadPlanStepOut. Add a convenience API ABI::GetReturnValueObject. Change the ValueObject::EvaluationPoint to BE an ExecutionContextScope, rather than trying to hand out one of its subsidiary object's pointers. That way this will always be good. llvm-svn: 146806
2011-12-17 09:35:57 +08:00
ABI for the Hexagon DSP llvm-svn: 213566
2014-07-22 01:21:01 +08:00
bool ABI::PrepareTrivialCall(Thread &thread, lldb::addr_t sp,
lldb::addr_t functionAddress,
lldb::addr_t returnAddress, llvm::Type &returntype,
llvm::ArrayRef<ABI::CallArgument> args) const {
// dummy prepare trivial call
Make lldb -Werror clean for -Wstring-conversion Also found/fixed one bug identified by this warning in RenderScriptx86ABIFixups.cpp where a string literal was being used in an effort to provide a name for an instruction/register, but was instead being passed as the bool 'isVolatile' parameter. llvm-svn: 291198
2017-01-06 08:38:06 +08:00
llvm_unreachable("Should never get here!");
ABI for the Hexagon DSP llvm-svn: 213566
2014-07-22 01:21:01 +08:00
}
Add new ABI callback to provide fallback unwind register locations If the UnwindPlan did not identify how to unwind the stack pointer register, LLDB currently assumes it can determine to caller's SP from the current frame's CFA. This is true on most platforms where CFA is by definition equal to the incoming SP at function entry. However, on the s390x target, we instead define the CFA to equal the incoming SP plus an offset of 160 bytes. This is because our ABI defines that the caller has to provide a register save area of size 160 bytes. This area is allocated by the caller, but is considered part of the callee's stack frame, and therefore the CFA is defined as pointing to the top of this area. In order to make this work on s390x, this patch introduces a new ABI callback GetFallbackRegisterLocation that provides platform- specific fallback register locations for unwinding. The existing code to handle SP unwinding as well as volatile registers is moved into the default implementation of that ABI callback, to allow targets where that implementation is incorrect to override it. This patch in itself is a no-op for all existing platforms. But it is a pre-requisite for adding s390x support. Differential Revision: http://reviews.llvm.org/D18977 llvm-svn: 266307
2016-04-14 22:25:20 +08:00
bool ABI::GetFallbackRegisterLocation(
const RegisterInfo *reg_info,
UnwindPlan::Row::RegisterLocation &unwind_regloc) {
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// Did the UnwindPlan fail to give us the caller's stack pointer? The stack
// pointer is defined to be the same as THIS frame's CFA, so return the CFA
// value as the caller's stack pointer. This is true on x86-32/x86-64 at
// least.
Add new ABI callback to provide fallback unwind register locations If the UnwindPlan did not identify how to unwind the stack pointer register, LLDB currently assumes it can determine to caller's SP from the current frame's CFA. This is true on most platforms where CFA is by definition equal to the incoming SP at function entry. However, on the s390x target, we instead define the CFA to equal the incoming SP plus an offset of 160 bytes. This is because our ABI defines that the caller has to provide a register save area of size 160 bytes. This area is allocated by the caller, but is considered part of the callee's stack frame, and therefore the CFA is defined as pointing to the top of this area. In order to make this work on s390x, this patch introduces a new ABI callback GetFallbackRegisterLocation that provides platform- specific fallback register locations for unwinding. The existing code to handle SP unwinding as well as volatile registers is moved into the default implementation of that ABI callback, to allow targets where that implementation is incorrect to override it. This patch in itself is a no-op for all existing platforms. But it is a pre-requisite for adding s390x support. Differential Revision: http://reviews.llvm.org/D18977 llvm-svn: 266307
2016-04-14 22:25:20 +08:00
if (reg_info->kinds[eRegisterKindGeneric] == LLDB_REGNUM_GENERIC_SP) {
unwind_regloc.SetIsCFAPlusOffset(0);
return true;
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Add new ABI callback to provide fallback unwind register locations If the UnwindPlan did not identify how to unwind the stack pointer register, LLDB currently assumes it can determine to caller's SP from the current frame's CFA. This is true on most platforms where CFA is by definition equal to the incoming SP at function entry. However, on the s390x target, we instead define the CFA to equal the incoming SP plus an offset of 160 bytes. This is because our ABI defines that the caller has to provide a register save area of size 160 bytes. This area is allocated by the caller, but is considered part of the callee's stack frame, and therefore the CFA is defined as pointing to the top of this area. In order to make this work on s390x, this patch introduces a new ABI callback GetFallbackRegisterLocation that provides platform- specific fallback register locations for unwinding. The existing code to handle SP unwinding as well as volatile registers is moved into the default implementation of that ABI callback, to allow targets where that implementation is incorrect to override it. This patch in itself is a no-op for all existing platforms. But it is a pre-requisite for adding s390x support. Differential Revision: http://reviews.llvm.org/D18977 llvm-svn: 266307
2016-04-14 22:25:20 +08:00
// If a volatile register is being requested, we don't want to forward the
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// next frame's register contents up the stack -- the register is not
// retrievable at this frame.
Add new ABI callback to provide fallback unwind register locations If the UnwindPlan did not identify how to unwind the stack pointer register, LLDB currently assumes it can determine to caller's SP from the current frame's CFA. This is true on most platforms where CFA is by definition equal to the incoming SP at function entry. However, on the s390x target, we instead define the CFA to equal the incoming SP plus an offset of 160 bytes. This is because our ABI defines that the caller has to provide a register save area of size 160 bytes. This area is allocated by the caller, but is considered part of the callee's stack frame, and therefore the CFA is defined as pointing to the top of this area. In order to make this work on s390x, this patch introduces a new ABI callback GetFallbackRegisterLocation that provides platform- specific fallback register locations for unwinding. The existing code to handle SP unwinding as well as volatile registers is moved into the default implementation of that ABI callback, to allow targets where that implementation is incorrect to override it. This patch in itself is a no-op for all existing platforms. But it is a pre-requisite for adding s390x support. Differential Revision: http://reviews.llvm.org/D18977 llvm-svn: 266307
2016-04-14 22:25:20 +08:00
if (RegisterIsVolatile(reg_info)) {
unwind_regloc.SetUndefined();
return true;
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Add new ABI callback to provide fallback unwind register locations If the UnwindPlan did not identify how to unwind the stack pointer register, LLDB currently assumes it can determine to caller's SP from the current frame's CFA. This is true on most platforms where CFA is by definition equal to the incoming SP at function entry. However, on the s390x target, we instead define the CFA to equal the incoming SP plus an offset of 160 bytes. This is because our ABI defines that the caller has to provide a register save area of size 160 bytes. This area is allocated by the caller, but is considered part of the callee's stack frame, and therefore the CFA is defined as pointing to the top of this area. In order to make this work on s390x, this patch introduces a new ABI callback GetFallbackRegisterLocation that provides platform- specific fallback register locations for unwinding. The existing code to handle SP unwinding as well as volatile registers is moved into the default implementation of that ABI callback, to allow targets where that implementation is incorrect to override it. This patch in itself is a no-op for all existing platforms. But it is a pre-requisite for adding s390x support. Differential Revision: http://reviews.llvm.org/D18977 llvm-svn: 266307
2016-04-14 22:25:20 +08:00
return false;
}
Have ABI plugins vend llvm MCRegisterInfo data Summary: I was recently surprised to learn that there is a total of 2 (two) users of the register info definitions contained in the ABI plugins. Yet, the defitions themselves span nearly 10kLOC. The two users are: - dwarf expression pretty printer - the mechanism for augmenting the register info definitions obtained over gdb-remote protocol (AugmentRegisterInfoViaABI) Both of these uses need the DWARF an EH register numbers, which is information that is already available in LLVM. This patch makes it possible to do so. It adds a GetMCRegisterInfo method to the ABI class, which every class is expected to implement. Normally, it should be sufficient to obtain the definitions from the appropriate llvm::Target object (for which I provide a utility function), but the subclasses are free to construct it in any way they deem fit. We should be able to always get the MCRegisterInfo object from llvm, with one important exception: if the relevant llvm target was disabled at compile time. To handle this, I add a mechanism to disable the compilation of ABI plugins based on the value of LLVM_TARGETS_TO_BUILD cmake setting. This ensures all our existing are able to create their MCRegisterInfo objects. The new MCRegisterInfo api is not used yet, but the intention is to make use of it in follow-up patches. Reviewers: jasonmolenda, aprantl, JDevlieghere, tatyana-krasnukha Subscribers: wuzish, nemanjai, mgorny, kbarton, atanasyan, lldb-commits Differential Revision: https://reviews.llvm.org/D67965 llvm-svn: 372862
2019-09-25 21:03:04 +08:00
std::unique_ptr<llvm::MCRegisterInfo> ABI::MakeMCRegisterInfo(const ArchSpec &arch) {
std::string triple = arch.GetTriple().getTriple();
std::string lookup_error;
const llvm::Target *target =
llvm::TargetRegistry::lookupTarget(triple, lookup_error);
if (!target) {
LLDB_LOG(GetLogIfAllCategoriesSet(LIBLLDB_LOG_PROCESS),
"Failed to create an llvm target for {0}: {1}", triple,
lookup_error);
return nullptr;
}
std::unique_ptr<llvm::MCRegisterInfo> info_up(
target->createMCRegInfo(triple));
assert(info_up);
return info_up;
}
[lldb] Move register info "augmentation" from gdb-remote into ABI Summary: Previously the ABI plugin exposed some "register infos" and the gdb-remote code used those to fill in the missing bits. Now, the "filling in" code is in the ABI plugin itself, and the gdb-remote code just invokes that. The motivation for this is two-fold: a) the "augmentation" logic is useful outside of process gdb-remote. For instance, it would allow us to avoid repeating the register number definitions in minidump code. b) It gives more implementation freedom to the ABI classes. Now that these "register infos" are essentially implementation details, classes can use other methods to obtain dwarf/eh_frame register numbers -- for instance they can consult llvm MC layer. Since the augmentation code was not currently tested anywhere, I took the opportunity to create a simple test for it. Reviewers: jasonmolenda, clayborg, tatyana-krasnukha Subscribers: aprantl, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70906
2019-12-03 18:39:20 +08:00
[lldb] Introduce "RegInfoBasedABI" Summary: This patch creates a new subclass of the ABI class in order to abstract away the mechanism in which we "augment" register information. This enables alternate augmentation strategies to be introduced. All existing ABI classes have been modified to inherit from RegInfoBasedABI, but they will be refactored in subsequent patches. Reviewers: JDevlieghere, jasonmolenda Subscribers: sdardis, nemanjai, kbarton, jrtc27, atanasyan, jsji, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D74243
2020-02-02 17:27:40 +08:00
void RegInfoBasedABI::AugmentRegisterInfo(RegisterInfo &info) {
[lldb] Move register info "augmentation" from gdb-remote into ABI Summary: Previously the ABI plugin exposed some "register infos" and the gdb-remote code used those to fill in the missing bits. Now, the "filling in" code is in the ABI plugin itself, and the gdb-remote code just invokes that. The motivation for this is two-fold: a) the "augmentation" logic is useful outside of process gdb-remote. For instance, it would allow us to avoid repeating the register number definitions in minidump code. b) It gives more implementation freedom to the ABI classes. Now that these "register infos" are essentially implementation details, classes can use other methods to obtain dwarf/eh_frame register numbers -- for instance they can consult llvm MC layer. Since the augmentation code was not currently tested anywhere, I took the opportunity to create a simple test for it. Reviewers: jasonmolenda, clayborg, tatyana-krasnukha Subscribers: aprantl, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70906
2019-12-03 18:39:20 +08:00
if (info.kinds[eRegisterKindEHFrame] != LLDB_INVALID_REGNUM &&
info.kinds[eRegisterKindDWARF] != LLDB_INVALID_REGNUM)
return;
RegisterInfo abi_info;
[lldb] Remove all the RegisterInfo name constification code RegisterInfo's `reg_name`/`reg_alt_name` fields are C-Strings and are supposed to only be generated from a ConstString. The reason for that is that `DynamicRegisterInfo::GetRegisterInfo` and `RegInfoBasedABI::GetRegisterInfoByName` try to optimise finding registers by name by only comparing the C string pointer values instead of the underlying strings. This only works if both C strings involved in the comparison come from a ConstString. If one of the two C strings doesn't come from a ConstString the comparison won't work (and most likely will silently fail). I added an assert in b0060c3a7868ef026d95d0cf8a076791ef74f474 which checks that both strings come from a ConstString. Apparently not all ABI plugins are generating their register names via ConstString, so this code is now not just silently failing but also asserting. In D88375 we did a shady fix for the MIPS plugins by just copying the ConstString 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 requirement to have the register names coming from ConstStrings. I really doubt that we actually save any time with the whole ConstString search trick (searching ~50 strings that have <4 characters doesn't sound more expensive than calling the really expensive ConstString constructor + comparing the same amount of pointer values). Also whatever small percentage of LLDB's runtime is actually spend in this 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, labath Differential Revision: https://reviews.llvm.org/D88490
2020-10-13 23:10:10 +08:00
if (!GetRegisterInfoByName(info.name, abi_info))
[lldb] Move register info "augmentation" from gdb-remote into ABI Summary: Previously the ABI plugin exposed some "register infos" and the gdb-remote code used those to fill in the missing bits. Now, the "filling in" code is in the ABI plugin itself, and the gdb-remote code just invokes that. The motivation for this is two-fold: a) the "augmentation" logic is useful outside of process gdb-remote. For instance, it would allow us to avoid repeating the register number definitions in minidump code. b) It gives more implementation freedom to the ABI classes. Now that these "register infos" are essentially implementation details, classes can use other methods to obtain dwarf/eh_frame register numbers -- for instance they can consult llvm MC layer. Since the augmentation code was not currently tested anywhere, I took the opportunity to create a simple test for it. Reviewers: jasonmolenda, clayborg, tatyana-krasnukha Subscribers: aprantl, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70906
2019-12-03 18:39:20 +08:00
return;
if (info.kinds[eRegisterKindEHFrame] == LLDB_INVALID_REGNUM)
info.kinds[eRegisterKindEHFrame] = abi_info.kinds[eRegisterKindEHFrame];
if (info.kinds[eRegisterKindDWARF] == LLDB_INVALID_REGNUM)
info.kinds[eRegisterKindDWARF] = abi_info.kinds[eRegisterKindDWARF];
if (info.kinds[eRegisterKindGeneric] == LLDB_INVALID_REGNUM)
info.kinds[eRegisterKindGeneric] = abi_info.kinds[eRegisterKindGeneric];
}
[lldb] Delete register info definitions in the x86_64 ABI classes Summary: These definitions are used to "augment" information received from the remote target with eh/debug frame and "generic" register numbers. Besides being verbose, this information was also incomplete (new registers like xmm16-31 were missing) and sometimes even downright wrong (ymm register numbers). Most of this information is available via llvm's MCRegisterInfo. This patch creates a new class, MCBasedABI, which retrieves the eh and debug frame register numbers this way. The tricky part here is that the llvm class uses all-caps register names, whereas lldb register are lowercase, and sometimes called slightly differently. Therefore this class introduces some hooks to allow a subclass to customize the MC lookup. The subclass also needs to suply the "generic" register numbers, as this is an lldb invention. This patch ports the x86_64 ABI classes to use the new register info mechanism. It also creates a new "ABIx86_64" class which can be used to house code common to x86_64 both ABIs. Right now, this just consists of a single function, but there are plenty of other things that could be moved here too. Reviewers: JDevlieghere, jasonmolenda Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D74244
2020-02-04 00:58:37 +08:00
void MCBasedABI::AugmentRegisterInfo(RegisterInfo &info) {
uint32_t eh, dwarf;
std::tie(eh, dwarf) = GetEHAndDWARFNums(info.name);
if (info.kinds[eRegisterKindEHFrame] == LLDB_INVALID_REGNUM)
info.kinds[eRegisterKindEHFrame] = eh;
if (info.kinds[eRegisterKindDWARF] == LLDB_INVALID_REGNUM)
info.kinds[eRegisterKindDWARF] = dwarf;
if (info.kinds[eRegisterKindGeneric] == LLDB_INVALID_REGNUM)
info.kinds[eRegisterKindGeneric] = GetGenericNum(info.name);
}
std::pair<uint32_t, uint32_t>
MCBasedABI::GetEHAndDWARFNums(llvm::StringRef name) {
std::string mc_name = GetMCName(name.str());
[lldb] Fix build error from 07355c1c08b The error is: no matching function for call to 'transform(std::string&, std::__cxx11::basic_string<char>::iterator, <unresolved overloaded function type>)' The fix: replace llvm::transform with an equally simple hand-rolled loop.
2020-02-17 21:12:29 +08:00
for (char &c : mc_name)
c = std::toupper(c);
[lldb] Delete register info definitions in the x86_64 ABI classes Summary: These definitions are used to "augment" information received from the remote target with eh/debug frame and "generic" register numbers. Besides being verbose, this information was also incomplete (new registers like xmm16-31 were missing) and sometimes even downright wrong (ymm register numbers). Most of this information is available via llvm's MCRegisterInfo. This patch creates a new class, MCBasedABI, which retrieves the eh and debug frame register numbers this way. The tricky part here is that the llvm class uses all-caps register names, whereas lldb register are lowercase, and sometimes called slightly differently. Therefore this class introduces some hooks to allow a subclass to customize the MC lookup. The subclass also needs to suply the "generic" register numbers, as this is an lldb invention. This patch ports the x86_64 ABI classes to use the new register info mechanism. It also creates a new "ABIx86_64" class which can be used to house code common to x86_64 both ABIs. Right now, this just consists of a single function, but there are plenty of other things that could be moved here too. Reviewers: JDevlieghere, jasonmolenda Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D74244
2020-02-04 00:58:37 +08:00
int eh = -1;
int dwarf = -1;
for (unsigned reg = 0; reg < m_mc_register_info_up->getNumRegs(); ++reg) {
if (m_mc_register_info_up->getName(reg) == mc_name) {
eh = m_mc_register_info_up->getDwarfRegNum(reg, /*isEH=*/true);
dwarf = m_mc_register_info_up->getDwarfRegNum(reg, /*isEH=*/false);
break;
}
}
return std::pair<uint32_t, uint32_t>(eh == -1 ? LLDB_INVALID_REGNUM : eh,
dwarf == -1 ? LLDB_INVALID_REGNUM
: dwarf);
}
void MCBasedABI::MapRegisterName(std::string &name, llvm::StringRef from_prefix,
llvm::StringRef to_prefix) {
llvm::StringRef name_ref = name;
if (!name_ref.consume_front(from_prefix))
return;
uint64_t _;
if (name_ref.empty() || to_integer(name_ref, _, 10))
name = (to_prefix + name_ref).str();
}