[Lldb-commits] [PATCH] D39844: CompilerType: Add ability to retrieve an integral template argument
labath updated this revision to Diff 122407.
labath marked 3 inline comments as done.
labath added a comment.
- provide default no-op implementations in TypeSystem, so derived classes don't
have to override them if they don't want to
- have SBType::GetTemplateArgumentType return the type of the integral value
for integral template arguments
- more tests: I have added a test to check we correctly see through the "auto"
type and that the functions (correctly) return empty values when called on an
argument of the wrong kind.
https://reviews.llvm.org/D39844
Files:
include/lldb/Symbol/ClangASTContext.h
include/lldb/Symbol/CompilerType.h
include/lldb/Symbol/GoASTContext.h
include/lldb/Symbol/JavaASTContext.h
include/lldb/Symbol/OCamlASTContext.h
include/lldb/Symbol/TypeSystem.h
include/lldb/lldb-enumerations.h
source/API/SBType.cpp
source/Plugins/Language/CPlusPlus/LibCxx.cpp
source/Plugins/Language/CPlusPlus/LibCxxInitializerList.cpp
source/Plugins/Language/CPlusPlus/LibCxxList.cpp
source/Plugins/Language/CPlusPlus/LibCxxMap.cpp
source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp
source/Plugins/Language/CPlusPlus/LibCxxVector.cpp
source/Plugins/Language/CPlusPlus/LibStdcpp.cpp
source/Symbol/ClangASTContext.cpp
source/Symbol/CompilerType.cpp
source/Symbol/JavaASTContext.cpp
source/Symbol/TypeSystem.cpp
unittests/Symbol/TestClangASTContext.cpp
Index: unittests/Symbol/TestClangASTContext.cpp
===
--- unittests/Symbol/TestClangASTContext.cpp
+++ unittests/Symbol/TestClangASTContext.cpp
@@ -406,18 +406,28 @@
type, "foo_def",
CompilerDeclContext(m_ast.get(), m_ast->GetTranslationUnitDecl()));
+ CompilerType auto_type(m_ast->getASTContext(),
+ m_ast->getASTContext()->getAutoType(
+ ClangUtil::GetCanonicalQualType(typedef_type),
+ clang::AutoTypeKeyword::Auto, false));
+
CompilerType int_type(m_ast->getASTContext(), m_ast->getASTContext()->IntTy);
- for(CompilerType t: { type, typedef_type }) {
+ for(CompilerType t: { type, typedef_type, auto_type }) {
SCOPED_TRACE(t.GetTypeName().AsCString());
-TemplateArgumentKind kind;
-
-CompilerType arg =
-m_ast->GetTemplateArgument(t.GetOpaqueQualType(), 0, kind);
-EXPECT_EQ(kind, eTemplateArgumentKindType);
-EXPECT_EQ(arg, int_type);
-arg = m_ast->GetTemplateArgument(t.GetOpaqueQualType(), 1, kind);
-EXPECT_EQ(kind, eTemplateArgumentKindIntegral);
-EXPECT_EQ(arg, int_type);
+EXPECT_EQ(m_ast->GetTemplateArgumentKind(t.GetOpaqueQualType(), 0),
+ eTemplateArgumentKindType);
+EXPECT_EQ(m_ast->GetTypeTemplateArgument(t.GetOpaqueQualType(), 0),
+ int_type);
+auto p = m_ast->GetIntegralTemplateArgument(t.GetOpaqueQualType(), 0);
+EXPECT_EQ(p.second, CompilerType());
+
+EXPECT_EQ(m_ast->GetTemplateArgumentKind(t.GetOpaqueQualType(), 1),
+ eTemplateArgumentKindIntegral);
+EXPECT_EQ(m_ast->GetTypeTemplateArgument(t.GetOpaqueQualType(), 1),
+ CompilerType());
+p = m_ast->GetIntegralTemplateArgument(t.GetOpaqueQualType(), 1);
+EXPECT_EQ(p.first, llvm::APSInt(47));
+EXPECT_EQ(p.second, int_type);
}
}
Index: source/Symbol/TypeSystem.cpp
===
--- source/Symbol/TypeSystem.cpp
+++ source/Symbol/TypeSystem.cpp
@@ -23,6 +23,7 @@
#include "lldb/Symbol/CompilerType.h"
using namespace lldb_private;
+using namespace lldb;
TypeSystem::TypeSystem(LLVMCastKind kind) : m_kind(kind), m_sym_file(nullptr) {}
@@ -100,6 +101,22 @@
return CompilerType(this, type);
}
+TemplateArgumentKind
+TypeSystem::GetTemplateArgumentKind(opaque_compiler_type_t type, size_t idx) {
+ return eTemplateArgumentKindNull;
+}
+
+CompilerType TypeSystem::GetTypeTemplateArgument(opaque_compiler_type_t type,
+ size_t idx) {
+ return CompilerType();
+}
+
+std::pair
+TypeSystem::GetIntegralTemplateArgument(opaque_compiler_type_t type,
+size_t idx) {
+ return {llvm::APSInt(0), CompilerType()};
+}
+
LazyBool TypeSystem::ShouldPrintAsOneLiner(void *type, ValueObject *valobj) {
return eLazyBoolCalculate;
}
Index: source/Symbol/JavaASTContext.cpp
===
--- source/Symbol/JavaASTContext.cpp
+++ source/Symbol/JavaASTContext.cpp
@@ -884,13 +884,6 @@
return 0;
}
-CompilerType
-JavaASTContext::GetTemplateArgument(lldb::opaque_compiler_type_t type,
-size_t idx,
-lldb::TemplateArgumentKind &kind) {
- return CompilerType();
-}
-
uint32_t JavaASTContext::GetNumFields(lldb::opaque_compiler_type_t type) {
if (JavaObjectType *obj =
llvm::dyn_cast(static_cast(type))) {
Index: source/Symbol/Compile
[Lldb-commits] [PATCH] D39681: Implement core dump debugging for PPC64le
labath accepted this revision. labath added a comment. This revision is now accepted and ready to land. Looks good, thank you. Just please make sure you change the file name at top of the new header file and add inclusion guards. Comment at: source/Plugins/Process/elf-core/elf-core-enums.h:1 +//===-- ProcessElfCore.cpp --*- C++ -*-===// +// labath wrote: > Please update the file name here and add header guards. I think you've missed this one. https://reviews.llvm.org/D39681 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r317881 - Clean up NativeRegisterContext
Author: labath Date: Fri Nov 10 03:05:49 2017 New Revision: 317881 URL: http://llvm.org/viewvc/llvm-project?rev=317881&view=rev Log: Clean up NativeRegisterContext Summary: This commit removes the concrete_frame_idx member from NativeRegisterContext and related functions, which was always set to zero and never used. I also change the native thread class to store a NativeRegisterContext as a unique_ptr (documenting the ownership) and make sure it is always initialized (most of the code was already blindly dereferencing the register context pointer, assuming it would always be present -- this makes its treatment consistent). Reviewers: eugene, clayborg, krytarowski Subscribers: aemerson, sdardis, nemanjai, javed.absar, arichardson, kristof.beyls, kbarton, uweigand, alexandreyy, lldb-commits Differential Revision: https://reviews.llvm.org/D39837 Modified: lldb/trunk/include/lldb/Host/common/NativeRegisterContext.h lldb/trunk/include/lldb/Host/common/NativeThreadProtocol.h lldb/trunk/include/lldb/lldb-private-forward.h lldb/trunk/source/Host/common/NativeProcessProtocol.cpp lldb/trunk/source/Host/common/NativeRegisterContext.cpp lldb/trunk/source/Host/common/NativeThreadProtocol.cpp lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux.cpp lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux.h lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.h lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.h lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.cpp lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.h lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_s390x.cpp lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_s390x.h lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.h lldb/trunk/source/Plugins/Process/Linux/NativeThreadLinux.cpp lldb/trunk/source/Plugins/Process/Linux/NativeThreadLinux.h lldb/trunk/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp lldb/trunk/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD.cpp lldb/trunk/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD.h lldb/trunk/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp lldb/trunk/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.h lldb/trunk/source/Plugins/Process/NetBSD/NativeThreadNetBSD.cpp lldb/trunk/source/Plugins/Process/NetBSD/NativeThreadNetBSD.h lldb/trunk/source/Plugins/Process/Utility/NativeRegisterContextRegisterInfo.cpp lldb/trunk/source/Plugins/Process/Utility/NativeRegisterContextRegisterInfo.h lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp Modified: lldb/trunk/include/lldb/Host/common/NativeRegisterContext.h URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/common/NativeRegisterContext.h?rev=317881&r1=317880&r2=317881&view=diff == --- lldb/trunk/include/lldb/Host/common/NativeRegisterContext.h (original) +++ lldb/trunk/include/lldb/Host/common/NativeRegisterContext.h Fri Nov 10 03:05:49 2017 @@ -27,8 +27,7 @@ public: //-- // Constructors and Destructors //-- - NativeRegisterContext(NativeThreadProtocol &thread, -uint32_t concrete_frame_idx); + NativeRegisterContext(NativeThreadProtocol &thread); virtual ~NativeRegisterContext(); @@ -184,8 +183,6 @@ protected: //-- NativeThreadProtocol &m_thread; // The thread that this register context belongs to. - uint32_t m_concrete_frame_idx; // The concrete frame index for this register - // context // uint32_t m_stop_id; // The stop ID that any data in this // context is valid for Modified: lldb/trunk/include/lldb/Host/common/NativeThreadProtocol.h URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/common/NativeThreadProtocol.h?rev=317881&r1=317880&r2=317881&view=diff == --- lldb/trunk/include/lldb/Host/common/NativeThreadProtocol.h (original) +++ lldb/trunk/in
[Lldb-commits] [PATCH] D39837: Clean up NativeRegisterContext
This revision was automatically updated to reflect the committed changes. Closed by commit rL317881: Clean up NativeRegisterContext (authored by labath). Repository: rL LLVM https://reviews.llvm.org/D39837 Files: lldb/trunk/include/lldb/Host/common/NativeRegisterContext.h lldb/trunk/include/lldb/Host/common/NativeThreadProtocol.h lldb/trunk/include/lldb/lldb-private-forward.h lldb/trunk/source/Host/common/NativeProcessProtocol.cpp lldb/trunk/source/Host/common/NativeRegisterContext.cpp lldb/trunk/source/Host/common/NativeThreadProtocol.cpp lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux.cpp lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux.h lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.h lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.h lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.cpp lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.h lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_s390x.cpp lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_s390x.h lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.h lldb/trunk/source/Plugins/Process/Linux/NativeThreadLinux.cpp lldb/trunk/source/Plugins/Process/Linux/NativeThreadLinux.h lldb/trunk/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp lldb/trunk/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD.cpp lldb/trunk/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD.h lldb/trunk/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp lldb/trunk/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.h lldb/trunk/source/Plugins/Process/NetBSD/NativeThreadNetBSD.cpp lldb/trunk/source/Plugins/Process/NetBSD/NativeThreadNetBSD.h lldb/trunk/source/Plugins/Process/Utility/NativeRegisterContextRegisterInfo.cpp lldb/trunk/source/Plugins/Process/Utility/NativeRegisterContextRegisterInfo.h lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp Index: lldb/trunk/include/lldb/lldb-private-forward.h === --- lldb/trunk/include/lldb/lldb-private-forward.h +++ lldb/trunk/include/lldb/lldb-private-forward.h @@ -30,8 +30,6 @@ // SP/WP decls. // --- typedef std::shared_ptr NativeBreakpointSP; -typedef std::shared_ptr -NativeRegisterContextSP; } #endif // #if defined(__cplusplus) Index: lldb/trunk/include/lldb/Host/common/NativeThreadProtocol.h === --- lldb/trunk/include/lldb/Host/common/NativeThreadProtocol.h +++ lldb/trunk/include/lldb/Host/common/NativeThreadProtocol.h @@ -30,7 +30,7 @@ virtual lldb::StateType GetState() = 0; - virtual NativeRegisterContextSP GetRegisterContext() = 0; + virtual NativeRegisterContext &GetRegisterContext() = 0; virtual Status ReadRegister(uint32_t reg, RegisterValue ®_value); Index: lldb/trunk/include/lldb/Host/common/NativeRegisterContext.h === --- lldb/trunk/include/lldb/Host/common/NativeRegisterContext.h +++ lldb/trunk/include/lldb/Host/common/NativeRegisterContext.h @@ -27,8 +27,7 @@ //-- // Constructors and Destructors //-- - NativeRegisterContext(NativeThreadProtocol &thread, -uint32_t concrete_frame_idx); + NativeRegisterContext(NativeThreadProtocol &thread); virtual ~NativeRegisterContext(); @@ -184,8 +183,6 @@ //-- NativeThreadProtocol &m_thread; // The thread that this register context belongs to. - uint32_t m_concrete_frame_idx; // The concrete frame index for this register - // context // uint32_t m_stop_id; // The stop ID that any data in this // context is valid for Index: lldb/trunk/source/Host/common/NativeThreadProtocol.cpp === --- lldb/trunk/source/Host/common/NativeThreadProtocol.cpp +++ lldb/trunk/source/Host/common/NativeThreadProtocol.cpp @@ -22,43 +22,33 @@ Status NativeThreadProtocol::ReadRegister(uint32_t reg,
[Lldb-commits] [PATCH] D39896: Remove last Host usage from ArchSpec
labath created this revision.
In https://reviews.llvm.org/D39387, I was quick to jump to conclusion that
ArchSpec has no
external dependencies. It turns there still was one call to
HostInfo::GetArchitecture left -- for implementing the "systemArch32"
architecture and friends.
Since GetAugmentedArchSpec is the place we handle these "incomplete"
triples that don't specify os or vendor and "systemArch" looks very much
like an incomplete triple, I move its handling there.
After this ArchSpec *really* does not have external dependencies, and
I'd like to move it to the Utility module as a follow-up.
https://reviews.llvm.org/D39896
Files:
include/lldb/Host/HostInfoBase.h
source/Core/ArchSpec.cpp
source/Host/common/HostInfoBase.cpp
source/Target/Platform.cpp
unittests/Host/HostInfoTest.cpp
Index: unittests/Host/HostInfoTest.cpp
===
--- unittests/Host/HostInfoTest.cpp
+++ unittests/Host/HostInfoTest.cpp
@@ -1,4 +1,4 @@
-//===-- HostTest.cpp *- C++ -*-===//
+//===-- HostInfoTest.cpp *- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
@@ -8,6 +8,7 @@
//===--===//
#include "lldb/Host/HostInfo.h"
+#include "lldb/lldb-defines.h"
#include "gtest/gtest.h"
using namespace lldb_private;
@@ -37,4 +38,8 @@
EXPECT_EQ(spec.GetTriple().getOS(), triple.getOS());
EXPECT_EQ(spec.GetTriple().getVendor(), triple.getVendor());
EXPECT_EQ(spec.GetTriple().getEnvironment(), triple.getEnvironment());
+
+ // Test LLDB_ARCH_DEFAULT
+ EXPECT_EQ(HostInfo::GetAugmentedArchSpec(LLDB_ARCH_DEFAULT),
+HostInfo::GetArchitecture(HostInfo::eArchKindDefault));
}
Index: source/Target/Platform.cpp
===
--- source/Target/Platform.cpp
+++ source/Target/Platform.cpp
@@ -976,6 +976,9 @@
if (!ArchSpec::ContainsOnlyArch(normalized_triple))
return ArchSpec(triple);
+ if (auto kind = HostInfo::ParseArchitectureKind(triple))
+return HostInfo::GetArchitecture(*kind);
+
ArchSpec compatible_arch;
ArchSpec raw_arch(triple);
if (!IsCompatibleArchitecture(raw_arch, false, &compatible_arch))
Index: source/Host/common/HostInfoBase.cpp
===
--- source/Host/common/HostInfoBase.cpp
+++ source/Host/common/HostInfoBase.cpp
@@ -103,6 +103,14 @@
: g_fields->m_host_arch_32;
}
+llvm::Optional HostInfoBase::ParseArchitectureKind(llvm::StringRef kind) {
+ return llvm::StringSwitch>(kind)
+ .Case(LLDB_ARCH_DEFAULT, eArchKindDefault)
+ .Case(LLDB_ARCH_DEFAULT_32BIT, eArchKind32)
+ .Case(LLDB_ARCH_DEFAULT_64BIT, eArchKind64)
+ .Default(llvm::None);
+}
+
bool HostInfoBase::GetLLDBPath(lldb::PathType type, FileSpec &file_spec) {
file_spec.Clear();
@@ -258,6 +266,9 @@
if (!ArchSpec::ContainsOnlyArch(normalized_triple))
return ArchSpec(triple);
+ if (auto kind = HostInfo::ParseArchitectureKind(triple))
+return HostInfo::GetArchitecture(*kind);
+
llvm::Triple host_triple(llvm::sys::getDefaultTargetTriple());
if (normalized_triple.getVendorName().empty())
Index: source/Core/ArchSpec.cpp
===
--- source/Core/ArchSpec.cpp
+++ source/Core/ArchSpec.cpp
@@ -9,7 +9,6 @@
#include "lldb/Core/ArchSpec.h"
-#include "lldb/Host/HostInfo.h"
#include "lldb/Utility/NameMatches.h"
#include "lldb/Utility/Stream.h" // for Stream
#include "lldb/Utility/StringList.h"
@@ -874,17 +873,7 @@
if (ParseMachCPUDashSubtypeTriple(triple, *this))
return true;
- if (triple.startswith(LLDB_ARCH_DEFAULT)) {
-// Special case for the current host default architectures...
-if (triple.equals(LLDB_ARCH_DEFAULT_32BIT))
- *this = HostInfo::GetArchitecture(HostInfo::eArchKind32);
-else if (triple.equals(LLDB_ARCH_DEFAULT_64BIT))
- *this = HostInfo::GetArchitecture(HostInfo::eArchKind64);
-else if (triple.equals(LLDB_ARCH_DEFAULT))
- *this = HostInfo::GetArchitecture(HostInfo::eArchKindDefault);
- } else {
-SetTriple(llvm::Triple(llvm::Triple::normalize(triple)));
- }
+ SetTriple(llvm::Triple(llvm::Triple::normalize(triple)));
return IsValid();
}
Index: include/lldb/Host/HostInfoBase.h
===
--- include/lldb/Host/HostInfoBase.h
+++ include/lldb/Host/HostInfoBase.h
@@ -61,6 +61,8 @@
static const ArchSpec &
GetArchitecture(ArchitectureKind arch_kind = eArchKindDefault);
+ static llvm::Optional ParseArchitectureKind(llvm::StringRef kind);
+
//--
/// Find a resource files that are related to LLDB.
///
__
[Lldb-commits] [PATCH] D39681: Implement core dump debugging for PPC64le
alexandreyy updated this revision to Diff 122423.
alexandreyy added a comment.
Added inclusion guards in elf-core-enums.h
https://reviews.llvm.org/D39681
Files:
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/linux-ppc64le.core
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/linux-ppc64le.out
source/Plugins/Process/Utility/CMakeLists.txt
source/Plugins/Process/Utility/RegisterContextPOSIX_ppc64le.cpp
source/Plugins/Process/Utility/RegisterContextPOSIX_ppc64le.h
source/Plugins/Process/elf-core/CMakeLists.txt
source/Plugins/Process/elf-core/ProcessElfCore.cpp
source/Plugins/Process/elf-core/RegisterContextPOSIXCore_ppc64le.cpp
source/Plugins/Process/elf-core/RegisterContextPOSIXCore_ppc64le.h
source/Plugins/Process/elf-core/ThreadElfCore.cpp
source/Plugins/Process/elf-core/ThreadElfCore.h
source/Plugins/Process/elf-core/elf-core-enums.h
Index: source/Plugins/Process/elf-core/elf-core-enums.h
===
--- /dev/null
+++ source/Plugins/Process/elf-core/elf-core-enums.h
@@ -0,0 +1,64 @@
+//===-- elf-core-enums.h *- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef elf_core_enums_h
+#define elf_core_enums_h
+
+/// Core files PT_NOTE segment descriptor types
+enum {
+ NT_PRSTATUS = 1,
+ NT_PRPSINFO = 3
+};
+
+namespace FREEBSD {
+ enum {
+NT_PRSTATUS = 1,
+NT_FPREGSET,
+NT_PRPSINFO,
+NT_THRMISC = 7,
+NT_PROCSTAT_AUXV = 16,
+NT_PPC_VMX = 0x100
+ };
+}
+
+namespace NETBSD {
+ enum {
+NT_PROCINFO = 1,
+NT_AUXV,
+NT_AMD64_REGS = 33,
+NT_AMD64_FPREGS = 35
+ };
+}
+
+namespace OPENBSD {
+ enum {
+NT_PROCINFO = 10,
+NT_AUXV = 11,
+NT_REGS = 20,
+NT_FPREGS = 21,
+ };
+}
+
+namespace LINUX {
+ enum {
+NT_PRSTATUS = 1,
+NT_FPREGSET,
+NT_PRPSINFO,
+NT_TASKSTRUCT,
+NT_PLATFORM,
+NT_AUXV,
+NT_FILE = 0x46494c45,
+NT_SIGINFO = 0x53494749,
+NT_PPC_VMX = 0x100,
+NT_PPC_VSX = 0x102,
+NT_PRXFPREG = 0x46e62b7f,
+ };
+}
+
+#endif // #ifndef elf_core_enums_h
Index: source/Plugins/Process/elf-core/ThreadElfCore.h
===
--- source/Plugins/Process/elf-core/ThreadElfCore.h
+++ source/Plugins/Process/elf-core/ThreadElfCore.h
@@ -18,6 +18,7 @@
// Project includes
#include "lldb/Target/Thread.h"
#include "lldb/Utility/DataExtractor.h"
+#include "llvm/ADT/DenseMap.h"
struct compat_timeval {
alignas(8) uint64_t tv_sec;
@@ -131,6 +132,7 @@
lldb_private::DataExtractor gpregset;
lldb_private::DataExtractor fpregset;
lldb_private::DataExtractor vregset;
+ llvm::DenseMap regsets;
lldb::tid_t tid;
int signo = 0;
int prstatus_sig = 0;
@@ -179,6 +181,7 @@
lldb_private::DataExtractor m_gpregset_data;
lldb_private::DataExtractor m_fpregset_data;
lldb_private::DataExtractor m_vregset_data;
+ llvm::DenseMap m_regsets_data;
bool CalculateStopInfo() override;
};
Index: source/Plugins/Process/elf-core/ThreadElfCore.cpp
===
--- source/Plugins/Process/elf-core/ThreadElfCore.cpp
+++ source/Plugins/Process/elf-core/ThreadElfCore.cpp
@@ -28,13 +28,15 @@
#include "Plugins/Process/Utility/RegisterContextOpenBSD_x86_64.h"
#include "Plugins/Process/Utility/RegisterInfoPOSIX_arm.h"
#include "Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h"
+#include "Plugins/Process/Utility/RegisterInfoPOSIX_ppc64le.h"
#include "ProcessElfCore.h"
#include "RegisterContextPOSIXCore_arm.h"
#include "RegisterContextPOSIXCore_arm64.h"
#include "RegisterContextPOSIXCore_mips64.h"
#include "RegisterContextPOSIXCore_powerpc.h"
#include "RegisterContextPOSIXCore_s390x.h"
#include "RegisterContextPOSIXCore_x86_64.h"
+#include "RegisterContextPOSIXCore_ppc64le.h"
#include "ThreadElfCore.h"
using namespace lldb;
@@ -46,7 +48,8 @@
ThreadElfCore::ThreadElfCore(Process &process, const ThreadData &td)
: Thread(process, td.tid), m_thread_name(td.name), m_thread_reg_ctx_sp(),
m_signo(td.signo), m_gpregset_data(td.gpregset),
- m_fpregset_data(td.fpregset), m_vregset_data(td.vregset) {}
+ m_fpregset_data(td.fpregset), m_vregset_data(td.vregset),
+ m_regsets_data(td.regsets) {}
ThreadElfCore::~ThreadElfCore() { DestroyThread(); }
@@ -142,6 +145,9 @@
case llvm::Triple::mips64:
reg_interface = new RegisterContextLinux_mips64(arch);
break;
+ case llvm::Triple::ppc64le:
+reg_interface = new RegisterInfoPOSIX_ppc64le(arch);
+break;
case llvm::Triple
[Lldb-commits] [PATCH] D39681: Implement core dump debugging for PPC64le
alexandreyy added a comment. In https://reviews.llvm.org/D39681#921620, @labath wrote: > Looks good, thank you. Just please make sure you change the file name at top > of the new header file and add inclusion guards. Done. Could you commit it? I don't have commit access. https://reviews.llvm.org/D39681 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D39896: Remove last Host usage from ArchSpec
Super awesome. When you do move it to Utility, can you run the deps python script to see if any cmake dependencies can be updated? On Fri, Nov 10, 2017 at 4:02 AM Pavel Labath via Phabricator < revi...@reviews.llvm.org> wrote: > labath created this revision. > > In https://reviews.llvm.org/D39387, I was quick to jump to conclusion > that ArchSpec has no > external dependencies. It turns there still was one call to > HostInfo::GetArchitecture left -- for implementing the "systemArch32" > architecture and friends. > > Since GetAugmentedArchSpec is the place we handle these "incomplete" > triples that don't specify os or vendor and "systemArch" looks very much > like an incomplete triple, I move its handling there. > > After this ArchSpec *really* does not have external dependencies, and > I'd like to move it to the Utility module as a follow-up. > > > https://reviews.llvm.org/D39896 > > Files: > include/lldb/Host/HostInfoBase.h > source/Core/ArchSpec.cpp > source/Host/common/HostInfoBase.cpp > source/Target/Platform.cpp > unittests/Host/HostInfoTest.cpp > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D39896: Remove last Host usage from ArchSpec
I'm not sure we have enough instances to decide on better organization, but ArchSpec really doesn't feel like a Utility for lldb. That would be like moving the llvm triple handling to ADT, that seems a little weird. Similarly having the register stuff in Utility seems odd as well. I would never think to look for it there. Pavel asked me a while ago to talk a bit about what the strategy for the directories in lldb was originally and I started to answer and then got sidetracked by events and never answered. The relevant historical bit for this discussion was originally the directory layout had nothing to do with building (Xcode doesn't care about files being in different directories, and we didn't envision building pieces of lldb separately at that point. I did it originally with the sole intent making an organization for people new to the code to find and remember where files were. We weren't super-rigorous about this - particularly as Xcode got better at finding files for you so finding them in directories was less important on our end. So for the purposes of reflecting code organization, we could probably stand another round of organization to make the structure more obvious. But I do think that's still a worthy goal. Anyway, then just because of the way cmake works (or is used in llvm I don't actually know which) we've switch the meaning of the directories to "files that are built into a .a file". And then, because of the need to shrink the code size of lldb-server, it became important to make at least the lower-level stuff that lldb-server depended on independent of as much of the rest of lldb as possible. So it became important for at least some directories to contain "files that are built into .a files that don't depend on some/most of the other .a files." That's introduced a somewhat orthogonal design principle for the directory layout. Note, Greg and I used to argue about the strategy for lldb-server. My notion was on modern systems the actual file size difference between an lldb-server that used all of lldb.framework, and one that could use a cut down library was really not all that important. If you're making a stub for an hard embedded system, you probably aren't going to use lldb-server, you'll use a much smaller gdb-protocol stub, and we didn't really have the intent to provide that functionality. So lldb server as intended for things like phones etc, where "small" means small in modern terms, not "a kilobyte matters" type small. I always felt the appropriate discipline to impose was making sure that if you didn't use something in lldb (symbols for instance) you don't pay memory/time cost for it. If that was true, and the bigger size was not an issue, than having lldb-server built with the full lldb.framework would mean that you would have flexibility to move work from the host to the lldb-server end of a remote debugging session, which could be really convenient since you could offload work to the remote end w/o having to come back over the slower remote communication channel. We never really convinced on another either way and since he directed most of the development of lldb-server on our end, he won by dint of implementation. But that's why for me the breakup of LLDB.framework into independent pieces was never a particularly present goal. Any, that's water under the bridge at this point. But I'd also like not to lose the benefit of comprehension that was the original reason for the directory layout. And in this instance, ArchSpec really doesn't seem like a Utility, which brought this back up in my thinking. There doesn't seem a critical mass of files in Utility to make decisions at this point, but as we break up Core, it might be nice to have a place for things that aren't Support or ADT type stuff, but more the core business of a debugger, but also don't drag in Symbol and other parts of lldb that aren't appropriate for lldb-server. Jim > On Nov 10, 2017, at 4:02 AM, Pavel Labath via Phabricator > wrote: > > labath created this revision. > > In https://reviews.llvm.org/D39387, I was quick to jump to conclusion that > ArchSpec has no > external dependencies. It turns there still was one call to > HostInfo::GetArchitecture left -- for implementing the "systemArch32" > architecture and friends. > > Since GetAugmentedArchSpec is the place we handle these "incomplete" > triples that don't specify os or vendor and "systemArch" looks very much > like an incomplete triple, I move its handling there. > > After this ArchSpec *really* does not have external dependencies, and > I'd like to move it to the Utility module as a follow-up. > > > https://reviews.llvm.org/D39896 > > Files: > include/lldb/Host/HostInfoBase.h > source/Core/ArchSpec.cpp > source/Host/common/HostInfoBase.cpp > source/Target/Platform.cpp > unittests/Host/HostInfoTest.cpp > > ___ lldb-commits
[Lldb-commits] [PATCH] D39896: Remove last Host usage from ArchSpec
clayborg added a comment. I just saw Jim's email for this, Please comment in this bug so we can all see the info in one location. Accepting pending the outcome of the discussion that Jim start in email that I am pasting below: > I'm not sure we have enough instances to decide on better organization, but > ArchSpec really doesn't feel like a Utility for lldb. That would be like > moving the llvm triple handling to ADT, that seems a little weird. Similarly > having the register stuff in Utility seems odd as well. I would never think > to look for it there. Pavel asked me a while ago to talk a bit about what > the strategy for the directories in lldb was originally and I started to > answer and then got sidetracked by events and never answered. > > The relevant historical bit for this discussion was originally the directory > layout had nothing to do with building (Xcode doesn't care about files being > in different directories, and we didn't envision building pieces of lldb > separately at that point. I did it originally with the sole intent making an > organization for people new to the code to find and remember where files > were. We weren't super-rigorous about this - particularly as Xcode got > better at finding files for you so finding them in directories was less > important on our end. So for the purposes of reflecting code organization, > we could probably stand another round of organization to make the structure > more obvious. But I do think that's still a worthy goal. > > Anyway, then just because of the way cmake works (or is used in llvm I don't > actually know which) we've switch the meaning of the directories to "files > that are built into a .a file". And then, because of the need to shrink the > code size of lldb-server, it became important to make at least the > lower-level stuff that lldb-server depended on independent of as much of the > rest of lldb as possible. So it became important for at least some > directories to contain "files that are built into .a files that don't depend > on some/most of the other .a files." That's introduced a somewhat orthogonal > design principle for the directory layout. > > Note, Greg and I used to argue about the strategy for lldb-server. My notion > was on modern systems the actual file size difference between an lldb-server > that used all of lldb.framework, and one that could use a cut down library > was really not all that important. If you're making a stub for an hard > embedded system, you probably aren't going to use lldb-server, you'll use a > much smaller gdb-protocol stub, and we didn't really have the intent to > provide that functionality. So lldb server as intended for things like > phones etc, where "small" means small in modern terms, not "a kilobyte > matters" type small. > > I always felt the appropriate discipline to impose was making sure that if > you didn't use something in lldb (symbols for instance) you don't pay > memory/time cost for it. If that was true, and the bigger size was not an > issue, than having lldb-server built with the full lldb.framework would mean > that you would have flexibility to move work from the host to the lldb-server > end of a remote debugging session, which could be really convenient since you > could offload work to the remote end w/o having to come back over the slower > remote communication channel. We never really convinced on another either > way and since he directed most of the development of lldb-server on our end, > he won by dint of implementation. But that's why for me the breakup of > LLDB.framework into independent pieces was never a particularly present goal. > > Any, that's water under the bridge at this point. But I'd also like not to > lose the benefit of comprehension that was the original reason for the > directory layout. And in this instance, ArchSpec really doesn't seem like a > Utility, which brought this back up in my thinking. There doesn't seem a > critical mass of files in Utility to make decisions at this point, but as we > break up Core, it might be nice to have a place for things that aren't > Support or ADT type stuff, but more the core business of a debugger, but also > don't drag in Symbol and other parts of lldb that aren't appropriate for > lldb-server. > > Jim https://reviews.llvm.org/D39896 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D39896: Remove last Host usage from ArchSpec
zturner added a comment. I'd be open to having another organizational component that isn't Utility. But as Jim said, there isn't a critical mass of stuff yet in Utility to figure out where it makes sense to draw the line. In all honesty, that second component might just end up being "Core" again, if enough stuff can be moved out of Core that it doesn't have to depend on Symbol, Host, Interpreter, Breakpoint, etc. BTW, I'm curious why you say that having Triple in llvm/ADT would be confusing. Isn't that where it already is? Or are you saying it's already confusing? There's been some discussion on the LLVM side recently about how Support is just a catch-all for random stuff that doesn't really belong anywhere else, and there seems to be general support for separating some things out. I actually made a small effort towards that end several months ago, when I took all of the object file format stuff out of Support and made a new target called BinaryFormat out of it. But, it was easy to see what the best way to do that was because there was already a critical mass of stuff there, so it was easy to identify a logical grouping that could be separated. https://reviews.llvm.org/D39896 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r317919 - [lldb] Remove unused method declaration
Author: alexshap Date: Fri Nov 10 11:40:53 2017 New Revision: 317919 URL: http://llvm.org/viewvc/llvm-project?rev=317919&view=rev Log: [lldb] Remove unused method declaration FindCompleteObjCDefinitionType is not used anywhere and there is no implementation of it, only a declaration. Test plan: make check-lldb Differential revision: https://reviews.llvm.org/D39884 Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h?rev=317919&r1=317918&r2=317919&view=diff == --- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h (original) +++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h Fri Nov 10 11:40:53 2017 @@ -396,10 +396,6 @@ protected: const DWARFDIE &die, const lldb_private::ConstString &type_name, bool must_be_implementation); - lldb::TypeSP - FindCompleteObjCDefinitionType(const lldb_private::ConstString &type_name, - bool header_definition_ok); - lldb_private::Symbol * GetObjCClassSymbol(const lldb_private::ConstString &objc_class_name); ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D39884: [lldb] Remove unused method declaration
This revision was automatically updated to reflect the committed changes. Closed by commit rL317919: [lldb] Remove unused method declaration (authored by alexshap). Changed prior to commit: https://reviews.llvm.org/D39884?vs=122379&id=122493#toc Repository: rL LLVM https://reviews.llvm.org/D39884 Files: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h === --- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h +++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h @@ -396,10 +396,6 @@ const DWARFDIE &die, const lldb_private::ConstString &type_name, bool must_be_implementation); - lldb::TypeSP - FindCompleteObjCDefinitionType(const lldb_private::ConstString &type_name, - bool header_definition_ok); - lldb_private::Symbol * GetObjCClassSymbol(const lldb_private::ConstString &objc_class_name); Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h === --- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h +++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h @@ -396,10 +396,6 @@ const DWARFDIE &die, const lldb_private::ConstString &type_name, bool must_be_implementation); - lldb::TypeSP - FindCompleteObjCDefinitionType(const lldb_private::ConstString &type_name, - bool header_definition_ok); - lldb_private::Symbol * GetObjCClassSymbol(const lldb_private::ConstString &objc_class_name); ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D39896: Remove last Host usage from ArchSpec
jingham added a comment. Yes, my intention was not to gate this patch on figuring out the right role for Utility/Core/Whatever. It just seemed an apropos moment to bring this up. You're right, the Triple stuff is in ADT! I was using it as an example of something you clearly wouldn't do so I didn't actually check to see if it was done. That's pretty funny. I thought that ADT stood for Abstract Data Types - though I actually I don't remember where I got that impression... Having Triple there does seem confusing. That is a "how we specify Targets type thing", not a fancy data type type thing... I would never think to look for that facility alongside StringRef & DenseMap etc. https://reviews.llvm.org/D39896 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D39896: Remove last Host usage from ArchSpec
probinson added a comment. Drive by comment: In https://reviews.llvm.org/D39896#94, @jingham wrote: > You're right, the Triple stuff is in ADT! I was using it as an example of > something you clearly wouldn't do so I didn't actually check to see if it was > done. That's pretty funny. > > I thought that ADT stood for Abstract Data Types - though I actually I don't > remember where I got that impression... Having Triple there does seem > confusing. That is a "how we specify Targets type thing", not a fancy data > type type thing... I would never think to look for that facility alongside > StringRef & DenseMap etc. Triple.h is in ADT; Triple.cpp is in Support. I agree it belongs in Support, and I'm not sure why it's schizo like that. https://reviews.llvm.org/D39896 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D39896: Remove last Host usage from ArchSpec
zturner added a comment. In https://reviews.llvm.org/D39896#922381, @probinson wrote: > Drive by comment: > > In https://reviews.llvm.org/D39896#94, @jingham wrote: > > > You're right, the Triple stuff is in ADT! I was using it as an example of > > something you clearly wouldn't do so I didn't actually check to see if it > > was done. That's pretty funny. > > > > I thought that ADT stood for Abstract Data Types - though I actually I > > don't remember where I got that impression... Having Triple there does > > seem confusing. That is a "how we specify Targets type thing", not a fancy > > data type type thing... I would never think to look for that facility > > alongside StringRef & DenseMap etc. > > > Triple.h is in ADT; Triple.cpp is in Support. I agree it belongs in Support, > and I'm not sure why it's schizo like that. Ok now that's just crazy. You're making me want to go fix this... https://reviews.llvm.org/D39896 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r317945 - Added a way to dump the full paths to all source files in a module that has debug info.
Author: gclayton Date: Fri Nov 10 14:39:07 2017 New Revision: 317945 URL: http://llvm.org/viewvc/llvm-project?rev=317945&view=rev Log: Added a way to dump the full paths to all source files in a module that has debug info. Modified: lldb/trunk/www/troubleshooting.html Modified: lldb/trunk/www/troubleshooting.html URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/www/troubleshooting.html?rev=317945&r1=317944&r2=317945&view=diff == --- lldb/trunk/www/troubleshooting.html (original) +++ lldb/trunk/www/troubleshooting.html Fri Nov 10 14:39:07 2017 @@ -79,6 +79,22 @@ 0 Above we can see that "/tmp/a.out" does have a compile unit, and "/usr/lib/dyld" does not. + We can also list the full paths to all compile units for a module using python: + +(lldb) script +Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D. +>>> m = lldb.target.module['a.out'] +>>> for i in range(m.GetNumCompileUnits()): +... cu = m.GetCompileUnitAtIndex(i).file.fullpath +/tmp/main.c +/tmp/foo.c +/tmp/bar.c +>>> + + This can help to show the actual full path to the source files. Sometimes IDEs will set breakpoints by full paths where the path doesn't match the full path in the debug info and this can cause LLDB to not resolve breakpoints. You can use the breakpoint list command with the --verbose option to see the full paths for any source file and line breakpoints that the IDE set using: + +(lldb) breakpoint list --verbose + ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
