[Lldb-commits] [lldb] af3c5a7 - Revert "[LLDB] Add more helper functions to CompilerType class."
Author: Caroline Tice
Date: 2023-11-26T17:03:35-08:00
New Revision: af3c5a7cf1e008a467eb3104424ed122b533d7b3
URL:
https://github.com/llvm/llvm-project/commit/af3c5a7cf1e008a467eb3104424ed122b533d7b3
DIFF:
https://github.com/llvm/llvm-project/commit/af3c5a7cf1e008a467eb3104424ed122b533d7b3.diff
LOG: Revert "[LLDB] Add more helper functions to CompilerType class."
PR 73467 was committed by accident. This undoes the premature commit.
Added:
Modified:
lldb/include/lldb/Symbol/CompilerType.h
lldb/source/Symbol/CompilerType.cpp
Removed:
diff --git a/lldb/include/lldb/Symbol/CompilerType.h
b/lldb/include/lldb/Symbol/CompilerType.h
index a3331ad3269c01d..0a9533a1ac0efc1 100644
--- a/lldb/include/lldb/Symbol/CompilerType.h
+++ b/lldb/include/lldb/Symbol/CompilerType.h
@@ -112,7 +112,9 @@ class CompilerType {
/// Tests.
/// \{
- explicit operator bool() const { return m_type_system.lock() && m_type; }
+ explicit operator bool() const {
+return m_type_system.lock() && m_type;
+ }
bool IsValid() const { return (bool)*this; }
@@ -192,54 +194,6 @@ class CompilerType {
bool IsTypedefType() const;
bool IsVoidType() const;
-
- bool IsSmartPtrType() const;
-
- bool IsInteger() const;
-
- bool IsFloat() const;
-
- bool IsEnumerationType() const;
-
- bool IsUnscopedEnumerationType() const;
-
- bool IsIntegerOrUnscopedEnumerationType() const;
-
- bool IsSigned() const;
-
- bool IsNullPtrType() const;
-
- bool IsBoolean() const;
-
- bool IsEnumerationIntegerTypeSigned() const;
-
- bool IsScalarOrUnscopedEnumerationType() const;
-
- bool IsPromotableIntegerType() const;
-
- bool IsPointerToVoid() const;
-
- bool IsRecordType() const;
-
- bool IsVirtualBase(CompilerType target_base, CompilerType *virtual_base,
- bool carry_virtual = false) const;
-
- bool IsContextuallyConvertibleToBool() const;
-
- bool IsBasicType() const;
-
- std::string TypeDescription();
-
- bool CompareTypes(CompilerType rhs) const;
-
- const char *GetTypeTag();
-
- uint32_t GetNumberOfNonEmptyBaseClasses();
-
- CompilerType GetTemplateArgumentType(uint32_t idx);
-
- CompilerType GetSmartPtrPointeeType();
-
/// \}
/// Type Completion.
@@ -482,8 +436,8 @@ class CompilerType {
ExecutionContextScope *exe_scope);
/// Dump to stdout.
- void DumpTypeDescription(
- lldb::DescriptionLevel level = lldb::eDescriptionLevelFull) const;
+ void DumpTypeDescription(lldb::DescriptionLevel level =
+ lldb::eDescriptionLevelFull) const;
/// Print a description of the type to a stream. The exact implementation
/// varies, but the expectation is that eDescriptionLevelFull returns a
diff --git a/lldb/source/Symbol/CompilerType.cpp
b/lldb/source/Symbol/CompilerType.cpp
index 854d6cab01b508e..78cc8dad94a9c5f 100644
--- a/lldb/source/Symbol/CompilerType.cpp
+++ b/lldb/source/Symbol/CompilerType.cpp
@@ -54,7 +54,7 @@ bool CompilerType::IsArrayType(CompilerType
*element_type_ptr, uint64_t *size,
if (IsValid())
if (auto type_system_sp = GetTypeSystem())
return type_system_sp->IsArrayType(m_type, element_type_ptr, size,
- is_incomplete);
+ is_incomplete);
if (element_type_ptr)
element_type_ptr->Clear();
@@ -157,8 +157,7 @@ bool CompilerType::IsBlockPointerType(
CompilerType *function_pointer_type_ptr) const {
if (IsValid())
if (auto type_system_sp = GetTypeSystem())
- return type_system_sp->IsBlockPointerType(m_type,
-function_pointer_type_ptr);
+ return type_system_sp->IsBlockPointerType(m_type,
function_pointer_type_ptr);
return false;
}
@@ -250,7 +249,7 @@ bool CompilerType::IsPossibleDynamicType(CompilerType
*dynamic_pointee_type,
if (IsValid())
if (auto type_system_sp = GetTypeSystem())
return type_system_sp->IsPossibleDynamicType(m_type,
dynamic_pointee_type,
- check_cplusplus,
check_objc);
+check_cplusplus, check_objc);
return false;
}
@@ -303,256 +302,6 @@ bool CompilerType::IsBeingDefined() const {
return false;
}
-bool CompilerType::IsSmartPtrType() const {
- // These regular expressions cover shared, unique and weak pointers both from
- // stdlibc++ and libc+++.
-
- static llvm::Regex k_libcxx_std_unique_ptr_regex(
- "^std::__[[:alnum:]]+::unique_ptr<.+>(( )?&)?$");
- static llvm::Regex k_libcxx_std_shared_ptr_regex(
- "^std::__[[:alnum:]]+::shared_ptr<.+>(( )?&)?$");
- static llvm::Regex k_libcxx_std_weak_ptr_regex(
- "^std::__[[:alnum:]]+::weak_ptr<.+>(( )?&)?$");
- //
- static llvm::Regex k_libcxx_std_unique_ptr_regex_2(
- "^std::unique_ptr<.+>(( )?&)?$");
- static llvm::Regex
[Lldb-commits] [lldb] 3885cea - [LLDB] Fix buffer overflow problem in DWARFExpression::Evaluate
Author: Caroline Tice
Date: 2023-07-10T19:47:38-07:00
New Revision: 3885ceafa9347dd729eba5cf872091a689b63d98
URL:
https://github.com/llvm/llvm-project/commit/3885ceafa9347dd729eba5cf872091a689b63d98
DIFF:
https://github.com/llvm/llvm-project/commit/3885ceafa9347dd729eba5cf872091a689b63d98.diff
LOG: [LLDB] Fix buffer overflow problem in DWARFExpression::Evaluate
In two calls to ReadMemory in DWARFExpression.cpp, the buffer size
passed to ReadMemory is not checked and can be bigger than the actual
size of the buffer. This caused a buffer overflow bug, which we
found through Address Sanitizer. This patch fixes the problem by
checking the address size when it is first read out of the DWARF, and
setting an error and returning immediatley if the size is invalid.
This is the second attempt to fix this issue; I reverted the first one,
as it was not quite correct.
Differential Revision: https://reviews.llvm.org/D154907
Added:
Modified:
lldb/source/Expression/DWARFExpression.cpp
Removed:
diff --git a/lldb/source/Expression/DWARFExpression.cpp
b/lldb/source/Expression/DWARFExpression.cpp
index 2e512bf7581e86..b829a6f7c86477 100644
--- a/lldb/source/Expression/DWARFExpression.cpp
+++ b/lldb/source/Expression/DWARFExpression.cpp
@@ -1069,6 +1069,13 @@ bool DWARFExpression::Evaluate(
return false;
}
uint8_t size = opcodes.GetU8();
+ if (size > 8) {
+if (error_ptr)
+ error_ptr->SetErrorStringWithFormat(
+ "Invalid address size for DW_OP_deref_size: %d\n",
+ size);
+return false;
+ }
Value::ValueType value_type = stack.back().GetValueType();
switch (value_type) {
case Value::ValueType::HostAddress: {
@@ -1141,7 +1148,7 @@ bool DWARFExpression::Evaluate(
} else {
if (error_ptr)
error_ptr->SetErrorStringWithFormat(
- "Failed to dereference pointer for for DW_OP_deref_size: "
+ "Failed to dereference pointer for DW_OP_deref_size: "
"%s\n",
error.AsCString());
return false;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 5f6c558 - Revert "[LLDB] Fix buffer overflow problem in DWARFExpression::Evaluate."
Author: Caroline Tice
Date: 2023-07-10T16:24:31-07:00
New Revision: 5f6c55836fb4666f3160400dc273deefdac82e06
URL:
https://github.com/llvm/llvm-project/commit/5f6c55836fb4666f3160400dc273deefdac82e06
DIFF:
https://github.com/llvm/llvm-project/commit/5f6c55836fb4666f3160400dc273deefdac82e06.diff
LOG: Revert "[LLDB] Fix buffer overflow problem in DWARFExpression::Evaluate."
This reverts commit ee476996bec7f170928505a4c5b7715183cfbada.
That commit was not the right way to fix the issue (it could result in
reading too many bytes). A better fix is in the works.
Original review: https://reviews.llvm.org/D153840
Added:
Modified:
lldb/source/Expression/DWARFExpression.cpp
Removed:
diff --git a/lldb/source/Expression/DWARFExpression.cpp
b/lldb/source/Expression/DWARFExpression.cpp
index c9524870f316f4..2e512bf7581e86 100644
--- a/lldb/source/Expression/DWARFExpression.cpp
+++ b/lldb/source/Expression/DWARFExpression.cpp
@@ -1127,16 +1127,15 @@ bool DWARFExpression::Evaluate(
if (load_addr == LLDB_INVALID_ADDRESS && so_addr.IsSectionOffset()) {
uint8_t addr_bytes[8];
- size_t buf_size = sizeof(addr_bytes);
Status error;
if (target &&
- target->ReadMemory(so_addr, _bytes, buf_size, error,
- /*force_live_memory=*/false) == buf_size) {
+ target->ReadMemory(so_addr, _bytes, size, error,
+ /*force_live_memory=*/false) == size) {
ObjectFile *objfile = module_sp->GetObjectFile();
stack.back().GetScalar() = DerefSizeExtractDataHelper(
-addr_bytes, size, objfile->GetByteOrder(), buf_size);
+addr_bytes, size, objfile->GetByteOrder(), size);
stack.back().ClearContext();
break;
} else {
@@ -1160,13 +1159,13 @@ bool DWARFExpression::Evaluate(
lldb::addr_t pointer_addr =
stack.back().GetScalar().ULongLong(LLDB_INVALID_ADDRESS);
uint8_t addr_bytes[sizeof(lldb::addr_t)];
-size_t buf_size = sizeof(addr_bytes);
Status error;
-if (process->ReadMemory(pointer_addr, _bytes, buf_size, error)
-== buf_size) {
+if (process->ReadMemory(pointer_addr, _bytes, size, error) ==
+size) {
+
stack.back().GetScalar() =
DerefSizeExtractDataHelper(addr_bytes, sizeof(addr_bytes),
- process->GetByteOrder(),
buf_size);
+ process->GetByteOrder(), size);
stack.back().ClearContext();
} else {
if (error_ptr)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] ee47699 - [LLDB] Fix buffer overflow problem in DWARFExpression::Evaluate.
Author: Caroline Tice
Date: 2023-06-28T11:46:55-07:00
New Revision: ee476996bec7f170928505a4c5b7715183cfbada
URL:
https://github.com/llvm/llvm-project/commit/ee476996bec7f170928505a4c5b7715183cfbada
DIFF:
https://github.com/llvm/llvm-project/commit/ee476996bec7f170928505a4c5b7715183cfbada.diff
LOG: [LLDB] Fix buffer overflow problem in DWARFExpression::Evaluate.
In two calls to ReadMemory in DWARFExpression.cpp, the buffer size
passed to ReadMemory is not actually the size of the buffer (I suspect
a copy/paste error where the variable name was not properly
updated). This caused a buffer overflow bug, which we found throuth
Address Sanitizer. This patch fixes the problem by passing the
correct buffer size to the calls to ReadMemory (and to the
DataExtractor).
Differential Revision: https://reviews.llvm.org/D153840
Added:
Modified:
lldb/source/Expression/DWARFExpression.cpp
Removed:
diff --git a/lldb/source/Expression/DWARFExpression.cpp
b/lldb/source/Expression/DWARFExpression.cpp
index 9232282d81353..5f71a12456972 100644
--- a/lldb/source/Expression/DWARFExpression.cpp
+++ b/lldb/source/Expression/DWARFExpression.cpp
@@ -1138,15 +1138,16 @@ bool DWARFExpression::Evaluate(
if (load_addr == LLDB_INVALID_ADDRESS && so_addr.IsSectionOffset()) {
uint8_t addr_bytes[8];
+ size_t buf_size = sizeof(addr_bytes);
Status error;
if (target &&
- target->ReadMemory(so_addr, _bytes, size, error,
- /*force_live_memory=*/false) == size) {
+ target->ReadMemory(so_addr, _bytes, buf_size, error,
+ /*force_live_memory=*/false) == buf_size) {
ObjectFile *objfile = module_sp->GetObjectFile();
stack.back().GetScalar() = DerefSizeExtractDataHelper(
-addr_bytes, size, objfile->GetByteOrder(), size);
+addr_bytes, size, objfile->GetByteOrder(), buf_size);
stack.back().ClearContext();
break;
} else {
@@ -1170,13 +1171,13 @@ bool DWARFExpression::Evaluate(
lldb::addr_t pointer_addr =
stack.back().GetScalar().ULongLong(LLDB_INVALID_ADDRESS);
uint8_t addr_bytes[sizeof(lldb::addr_t)];
+size_t buf_size = sizeof(addr_bytes);
Status error;
-if (process->ReadMemory(pointer_addr, _bytes, size, error) ==
-size) {
-
+if (process->ReadMemory(pointer_addr, _bytes, buf_size, error)
+== buf_size) {
stack.back().GetScalar() =
DerefSizeExtractDataHelper(addr_bytes, sizeof(addr_bytes),
- process->GetByteOrder(), size);
+ process->GetByteOrder(),
buf_size);
stack.back().ClearContext();
} else {
if (error_ptr)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 123f939 - [lldb] Fix language label in ObjC Language unittest
Author: Caroline Tice
Date: 2023-05-06T12:29:33-07:00
New Revision: 123f939c14f7a3c8e641d0348c1ad286538d4f1a
URL:
https://github.com/llvm/llvm-project/commit/123f939c14f7a3c8e641d0348c1ad286538d4f1a
DIFF:
https://github.com/llvm/llvm-project/commit/123f939c14f7a3c8e641d0348c1ad286538d4f1a.diff
LOG: [lldb] Fix language label in ObjC Language unittest
The recently added ObjC Language unittest, InvalidMethondNameParsing, currently
has CPlusPlusLanguage as its language label (see
https://reviews.llvm.org/D149804). There is already a test with the same name
and same language label in the C++ Language unittests, so this creates a name
conflict. This patch corrects the language label on the ObjC test.
Differential Revision: https://reviews.llvm.org/D150019
Added:
Modified:
lldb/unittests/Language/ObjC/ObjCLanguageTest.cpp
Removed:
diff --git a/lldb/unittests/Language/ObjC/ObjCLanguageTest.cpp
b/lldb/unittests/Language/ObjC/ObjCLanguageTest.cpp
index e9cb5d1b32143..683b16d5dcbed 100644
--- a/lldb/unittests/Language/ObjC/ObjCLanguageTest.cpp
+++ b/lldb/unittests/Language/ObjC/ObjCLanguageTest.cpp
@@ -92,7 +92,7 @@ TEST(ObjCLanguage, MethodNameParsing) {
}
}
-TEST(CPlusPlusLanguage, InvalidMethodNameParsing) {
+TEST(ObjCLanguage, InvalidMethodNameParsing) {
// Tests that we correctly reject malformed function names
llvm::StringRef test_cases[] = {"+[Uh oh!",
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] be58b42 - [lldb] Add 'CHECK' to class-type-nullptr-deref.s test.
Author: Caroline Tice Date: 2023-04-13T08:17:53-07:00 New Revision: be58b42a7510e3fe204e015bcf5faa9ed35d1766 URL: https://github.com/llvm/llvm-project/commit/be58b42a7510e3fe204e015bcf5faa9ed35d1766 DIFF: https://github.com/llvm/llvm-project/commit/be58b42a7510e3fe204e015bcf5faa9ed35d1766.diff LOG: [lldb] Add 'CHECK' to class-type-nullptr-deref.s test. This test previously relied on just segfaulting or not. This commit adds a CHECK statement to the test. Differential Revision: https://reviews.llvm.org/D148151 Added: Modified: lldb/test/Shell/SymbolFile/DWARF/x86/class-type-nullptr-deref.s Removed: diff --git a/lldb/test/Shell/SymbolFile/DWARF/x86/class-type-nullptr-deref.s b/lldb/test/Shell/SymbolFile/DWARF/x86/class-type-nullptr-deref.s index 610b45823458..c7aea06bf909 100644 --- a/lldb/test/Shell/SymbolFile/DWARF/x86/class-type-nullptr-deref.s +++ b/lldb/test/Shell/SymbolFile/DWARF/x86/class-type-nullptr-deref.s @@ -2,7 +2,9 @@ # null), LLDB does not try to dereference the null pointer. # RUN: llvm-mc --triple x86_64-pc-linux %s --filetype=obj -o %t -# RUN: %lldb %t -o "target variable x" -o exit 2>&1 +# RUN: %lldb %t -o "target variable x" -o exit 2>&1 | FileCheck %s + +# CHECK: 'Unable to determine byte size.' # This tests a fix for a crash. If things are working we don't get a segfault. ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 1fa26e6 - [PATCH][lldb] Fix dereference of null pointer.
Author: Caroline Tice Date: 2023-04-11T13:33:03-07:00 New Revision: 1fa26e64fd87c848ff54d08e9a14ea03e01ae645 URL: https://github.com/llvm/llvm-project/commit/1fa26e64fd87c848ff54d08e9a14ea03e01ae645 DIFF: https://github.com/llvm/llvm-project/commit/1fa26e64fd87c848ff54d08e9a14ea03e01ae645.diff LOG: [PATCH][lldb] Fix dereference of null pointer. The function DWARFASTParserClang::ParsePointerToMemberType attempts to make two pointers and then immediately tries to dereference them, without verifying that the pointesr were successfully created. Sometimes the pointer creation fails, and the dereference then causes a segfault. This add a check that the pointers are non-null before attempting to dereference them. Added: lldb/test/Shell/SymbolFile/DWARF/x86/class-type-nullptr-deref.s Modified: lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp Removed: diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp index cf794854c8431..e6921ca9cacdb 100644 --- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp +++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp @@ -1351,6 +1351,11 @@ TypeSP DWARFASTParserClang::ParsePointerToMemberType( Type *class_type = dwarf->ResolveTypeUID(attrs.containing_type.Reference(), true); + // Check to make sure pointers are not NULL before attempting to + // dereference them. + if ((class_type == nullptr) || (pointee_type == nullptr)) +return nullptr; + CompilerType pointee_clang_type = pointee_type->GetForwardCompilerType(); CompilerType class_clang_type = class_type->GetForwardCompilerType(); diff --git a/lldb/test/Shell/SymbolFile/DWARF/x86/class-type-nullptr-deref.s b/lldb/test/Shell/SymbolFile/DWARF/x86/class-type-nullptr-deref.s new file mode 100644 index 0..610b45823458b --- /dev/null +++ b/lldb/test/Shell/SymbolFile/DWARF/x86/class-type-nullptr-deref.s @@ -0,0 +1,66 @@ +# Test to verify that, if a class type pointer creation fails (pointer is +# null), LLDB does not try to dereference the null pointer. + +# RUN: llvm-mc --triple x86_64-pc-linux %s --filetype=obj -o %t +# RUN: %lldb %t -o "target variable x" -o exit 2>&1 + +# This tests a fix for a crash. If things are working we don't get a segfault. + +.type x,@object # @x +.bss +.globl x +x: +.quad 0 # 0x0 +.size x, 8 + +.section.debug_abbrev,"",@progbits +.byte 1 # Abbreviation Code +.byte 17 # DW_TAG_compile_unit +.byte 1 # DW_CHILDREN_yes +.byte 37 # DW_AT_producer +.byte 8 # DW_FORM_string +.byte 0 # EOM(1) +.byte 0 # EOM(2) +.byte 2 # Abbreviation Code +.byte 52 # DW_TAG_variable +.byte 0 # DW_CHILDREN_no +.byte 3 # DW_AT_name +.byte 8 # DW_FORM_string +.byte 73 # DW_AT_type +.byte 19 # DW_FORM_ref4 +.byte 2 # DW_AT_location +.byte 24 # DW_FORM_exprloc +.byte 0 # EOM(1) +.byte 0 # EOM(2) +.byte 3 # Abbreviation Code +.byte 31 # DW_TAG_ptr_to_member_type +.byte 0 # DW_CHILDREN_no +.byte 73 # DW_AT_type +.byte 19 # DW_FORM_ref4 +.byte 29 # DW_AT_containing_type +.byte 19 # DW_FORM_ref4 +.byte 0 # EOM(1) +.byte 0 # EOM(2) +.byte 0 # EOM(3) +.section.debug_info,"",@progbits +.Lcu_begin0: +.long .Ldebug_info_end0-.Ldebug_info_start0 # Length of Unit +.Ldebug_info_start0: +.short 5 # DWARF version number +.byte 1 # DWARF Unit Type +.byte 8 # Address Size (in bytes) +.long .debug_abbrev # Offset Into Abbrev. Section +.byte 1 # Abbrev [1] DW_TAG_compile_unit
[Lldb-commits] [lldb] 0591540 - [lldb] Replace SVE_PT* macros in NativeRegisterContextLinux_arm64.{cpp, h} with their equivalent defintions in LinuxPTraceDefines_arm64sve.h
Author: Caroline Tice
Date: 2021-06-30T09:26:20-07:00
New Revision: 05915400b7f9933b95686116f2dc1370e7f96cfb
URL:
https://github.com/llvm/llvm-project/commit/05915400b7f9933b95686116f2dc1370e7f96cfb
DIFF:
https://github.com/llvm/llvm-project/commit/05915400b7f9933b95686116f2dc1370e7f96cfb.diff
LOG: [lldb] Replace SVE_PT* macros in NativeRegisterContextLinux_arm64.{cpp,h}
with their equivalent defintions in LinuxPTraceDefines_arm64sve.h
Commit 090306fc80dbf (August 2020) changed most of the arm64 SVE_PT*
macros, but apparently did not make the changes in the
NativeRegisterContextLinux_arm64.* files (or those files were pulled
over from someplace else after that commit). This change replaces the
macros NativeRegisterContextLinux_arm64.cpp with the replacement
definitions in LinuxPTraceDefines_arm64sve.h. It also includes
LinuxPTraceDefines_arm64sve.h in NativeRegisterContextLinux_arm64.h.
Differential Revision: https://reviews.llvm.org/D104826
Added:
Modified:
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
Removed:
diff --git
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
index f78c0d2bb32fe..a0672a635937f 100644
--- a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
+++ b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
@@ -58,7 +58,7 @@
NativeRegisterContextLinux::CreateHostNativeRegisterContextLinux(
switch (target_arch.GetMachine()) {
case llvm::Triple::arm:
return std::make_unique(target_arch,
- native_thread);
+native_thread);
case llvm::Triple::aarch64: {
// Configure register sets supported by this AArch64 target.
// Read SVE header to check for SVE support.
@@ -207,15 +207,15 @@ NativeRegisterContextLinux_arm64::ReadRegister(const
RegisterInfo *reg_info,
if (reg == GetRegisterInfo().GetRegNumFPSR()) {
sve_reg_num = reg;
if (m_sve_state == SVEState::Full)
- offset = SVE_PT_SVE_FPSR_OFFSET(sve_vq_from_vl(m_sve_header.vl));
+ offset = sve::PTraceFPSROffset(sve::vq_from_vl(m_sve_header.vl));
else if (m_sve_state == SVEState::FPSIMD)
- offset = SVE_PT_FPSIMD_OFFSET + (32 * 16);
+ offset = sve::ptrace_fpsimd_offset + (32 * 16);
} else if (reg == GetRegisterInfo().GetRegNumFPCR()) {
sve_reg_num = reg;
if (m_sve_state == SVEState::Full)
- offset = SVE_PT_SVE_FPCR_OFFSET(sve_vq_from_vl(m_sve_header.vl));
+ offset = sve::PTraceFPCROffset(sve::vq_from_vl(m_sve_header.vl));
else if (m_sve_state == SVEState::FPSIMD)
- offset = SVE_PT_FPSIMD_OFFSET + (32 * 16) + 4;
+ offset = sve::ptrace_fpsimd_offset + (32 * 16) + 4;
} else {
// Extract SVE Z register value register number for this reg_info
if (reg_info->value_regs &&
@@ -341,15 +341,15 @@ Status NativeRegisterContextLinux_arm64::WriteRegister(
if (reg == GetRegisterInfo().GetRegNumFPSR()) {
sve_reg_num = reg;
if (m_sve_state == SVEState::Full)
- offset = SVE_PT_SVE_FPSR_OFFSET(sve_vq_from_vl(m_sve_header.vl));
+ offset = sve::PTraceFPSROffset(sve::vq_from_vl(m_sve_header.vl));
else if (m_sve_state == SVEState::FPSIMD)
- offset = SVE_PT_FPSIMD_OFFSET + (32 * 16);
+ offset = sve::ptrace_fpsimd_offset + (32 * 16);
} else if (reg == GetRegisterInfo().GetRegNumFPCR()) {
sve_reg_num = reg;
if (m_sve_state == SVEState::Full)
- offset = SVE_PT_SVE_FPCR_OFFSET(sve_vq_from_vl(m_sve_header.vl));
+ offset = sve::PTraceFPCROffset(sve::vq_from_vl(m_sve_header.vl));
else if (m_sve_state == SVEState::FPSIMD)
- offset = SVE_PT_FPSIMD_OFFSET + (32 * 16) + 4;
+ offset = sve::ptrace_fpsimd_offset + (32 * 16) + 4;
} else {
// Extract SVE Z register value register number for this reg_info
if (reg_info->value_regs &&
@@ -824,19 +824,21 @@ void
NativeRegisterContextLinux_arm64::ConfigureRegisterContext() {
if (error.Success()) {
// If SVE is enabled thread can switch between SVEState::FPSIMD and
// SVEState::Full on every stop.
- if ((m_sve_header.flags & SVE_PT_REGS_MASK) == SVE_PT_REGS_FPSIMD)
+ if ((m_sve_header.flags & sve::ptrace_regs_mask) ==
+ sve::ptrace_regs_fpsimd)
m_sve_state = SVEState::FPSIMD;
- else if ((m_sve_header.flags & SVE_PT_REGS_MASK) == SVE_PT_REGS_SVE)
+ else if ((m_sve_header.flags & sve::ptrace_regs_mask) ==
+ sve::ptrace_regs_sve)
m_sve_state = SVEState::Full;
[Lldb-commits] [lldb] 3dc24bc - [LLDB] Re-land: Use path relative to binary for finding .dwo files.
Author: Caroline Tice
Date: 2021-04-16T11:12:39-07:00
New Revision: 3dc24bc31edbc01dea085b24a6a6b024d7ae531c
URL:
https://github.com/llvm/llvm-project/commit/3dc24bc31edbc01dea085b24a6a6b024d7ae531c
DIFF:
https://github.com/llvm/llvm-project/commit/3dc24bc31edbc01dea085b24a6a6b024d7ae531c.diff
LOG: [LLDB] Re-land: Use path relative to binary for finding .dwo files.
DWARF allows .dwo file paths to be relative rather than absolute. When
they are relative, DWARF uses DW_AT_comp_dir to find the .dwo
file. DW_AT_comp_dir can also be relative, making the entire search
patch for the .dwo file relative. In this case, LLDB currently
searches relative to its current working directory, i.e. the directory
from which the debugger was launched. This is not right, as the
compiler, which generated the relative paths, can have no idea where
the debugger will be launched. The correct thing is to search relative
to the location of the executable binary. That is what this patch
does.
Differential Revision: https://reviews.llvm.org/D97786
Added:
lldb/test/Shell/SymbolFile/DWARF/dwo-relative-path.s
Modified:
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
Removed:
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 3a04f429c7c75..da170383405fb 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -1651,6 +1651,13 @@ SymbolFileDWARF::GetDwoSymbolFileForCompileUnit(
return nullptr;
dwo_file.SetFile(comp_dir, FileSpec::Style::native);
+if (dwo_file.IsRelative()) {
+ // if DW_AT_comp_dir is relative, it should be relative to the location
+ // of the executable, not to the location from which the debugger was
+ // launched.
+ dwo_file.PrependPathComponent(
+ m_objfile_sp->GetFileSpec().GetDirectory().GetStringRef());
+}
FileSystem::Instance().Resolve(dwo_file);
dwo_file.AppendPathComponent(dwo_name);
}
diff --git a/lldb/test/Shell/SymbolFile/DWARF/dwo-relative-path.s
b/lldb/test/Shell/SymbolFile/DWARF/dwo-relative-path.s
new file mode 100644
index 0..1916461e3ce8b
--- /dev/null
+++ b/lldb/test/Shell/SymbolFile/DWARF/dwo-relative-path.s
@@ -0,0 +1,173 @@
+# Test to verify LLDB searches for dwos with relative paths relative to the
+# binary location, not relative to LLDB's launch location.
+
+# RUN: llvm-mc --filetype=obj --triple x86_64-pc-linux %s -o %t.o
+# RUN: llvm-objcopy --split-dwo=%T/dwo-relative-path.dwo %t.o
+
+# RUN: cd ../..
+
+# RUN: %lldb %t.o -o "target var x" -b 2>&1 | FileCheck %s
+
+# CHECK: x = 10
+
+ .file "dwo-relative-path.cpp"
+ .file 0 "." "dwo-relative-path.cpp" md5
0xadc61d242247514c5d402d62db34b825
+ .type x,@object # @x
+ .data
+ .globl x
+ .p2align2
+x:
+ .long 10 # 0xa
+ .size x, 4
+
+ .section.debug_abbrev,"",@progbits
+ .byte 1 # Abbreviation Code
+ .byte 74 # DW_TAG_skeleton_unit
+ .byte 0 # DW_CHILDREN_no
+ .byte 16 # DW_AT_stmt_list
+ .byte 23 # DW_FORM_sec_offset
+ .byte 114 # DW_AT_str_offsets_base
+ .byte 23 # DW_FORM_sec_offset
+ .byte 27 # DW_AT_comp_dir
+ .byte 37 # DW_FORM_strx1
+ .ascii "\264B" # DW_AT_GNU_pubnames
+ .byte 25 # DW_FORM_flag_present
+ .byte 118 # DW_AT_dwo_name
+ .byte 37 # DW_FORM_strx1
+ .byte 115 # DW_AT_addr_base
+ .byte 23 # DW_FORM_sec_offset
+ .byte 0 # EOM(1)
+ .byte 0 # EOM(2)
+ .byte 0 # EOM(3)
+ .section.debug_info,"",@progbits
+.Lcu_begin0:
+ .long .Ldebug_info_end0-.Ldebug_info_start0 # Length of Unit
+.Ldebug_info_start0:
+ .short 5 # DWARF version number
+ .byte 4 # DWARF Unit Type
+ .byte 8 # Address Size (in bytes)
+ .long .debug_abbrev # Offset Into Abbrev. Section
+ .quad 3752513468363206953
+ .byte 1 # Abbrev [1] 0x14:0x14
DW_TAG_skeleton_unit
+ .long .Lline_table_start0 # DW_AT_stmt_list
+
[Lldb-commits] [lldb] 042668d - Revert "[LLDB] Use path relative to binary for finding .dwo files."
Author: Caroline Tice
Date: 2021-04-15T17:17:44-07:00
New Revision: 042668d092bb585e526023027faee8d28f968a76
URL:
https://github.com/llvm/llvm-project/commit/042668d092bb585e526023027faee8d28f968a76
DIFF:
https://github.com/llvm/llvm-project/commit/042668d092bb585e526023027faee8d28f968a76.diff
LOG: Revert "[LLDB] Use path relative to binary for finding .dwo files."
This reverts commit b241f3cb292d0ba1ad5a33b3bbd4a8a3a9c909dc.
Test case is breaking windows builder.
Added:
Modified:
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
Removed:
lldb/test/Shell/SymbolFile/DWARF/dwo-relative-path.s
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index da170383405f..3a04f429c7c7 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -1651,13 +1651,6 @@ SymbolFileDWARF::GetDwoSymbolFileForCompileUnit(
return nullptr;
dwo_file.SetFile(comp_dir, FileSpec::Style::native);
-if (dwo_file.IsRelative()) {
- // if DW_AT_comp_dir is relative, it should be relative to the location
- // of the executable, not to the location from which the debugger was
- // launched.
- dwo_file.PrependPathComponent(
- m_objfile_sp->GetFileSpec().GetDirectory().GetStringRef());
-}
FileSystem::Instance().Resolve(dwo_file);
dwo_file.AppendPathComponent(dwo_name);
}
diff --git a/lldb/test/Shell/SymbolFile/DWARF/dwo-relative-path.s
b/lldb/test/Shell/SymbolFile/DWARF/dwo-relative-path.s
deleted file mode 100644
index cc05434261e4..
--- a/lldb/test/Shell/SymbolFile/DWARF/dwo-relative-path.s
+++ /dev/null
@@ -1,417 +0,0 @@
-# Test to verify LLDB searches for dwos with relative paths relative to the
-# binary location, not relative to LLDB's launch location.
-
-# RUN: llvm-mc --filetype=obj --triple x86_64-pc-linux %s -o %t.o
-# RUN: llvm-objcopy --split-dwo=%T/dwo-relative-path.dwo %t.o
-
-# RUN: cd ../..
-
-# RUN: %lldb %t.o -o "target var x" -b 2>&1 | FileCheck %s
-
-# CHECK: x = 0
-
- .text
- .file "dwo-relative-path.cpp"
- .file 0 "." "dwo-relative-path.cpp" md5
0xadc61d242247514c5d402d62db34b825
- .globl main# -- Begin function main
- .p2align4, 0x90
- .type main,@function
-main: # @main
-.Lfunc_begin0:
- .loc0 14 0 # dwo-relative-path.cpp:14:0
- .cfi_startproc
-# %bb.0:# %entry
- pushq %rbp
- .cfi_def_cfa_offset 16
- .cfi_offset %rbp, -16
- movq%rsp, %rbp
- .cfi_def_cfa_register %rbp
- movl$0, -4(%rbp)
- movl%edi, -8(%rbp)
- movq%rsi, -16(%rbp)
-.Ltmp0:
- .loc0 15 8 prologue_end # dwo-relative-path.cpp:15:8
- movw.L__const.main.y, %ax
- movw%ax, -19(%rbp)
- movb.L__const.main.y+2, %al
- movb%al, -17(%rbp)
- .loc0 17 14 # dwo-relative-path.cpp:17:14
- movsbl -19(%rbp), %eax
- .loc0 17 27 is_stmt 0 # dwo-relative-path.cpp:17:27
- movsbl -18(%rbp), %ecx
- .loc0 17 19 # dwo-relative-path.cpp:17:19
- addl%ecx, %eax
- .loc0 17 5 # dwo-relative-path.cpp:17:5
- addlx, %eax
- movl%eax, x
- .loc0 19 3 is_stmt 1# dwo-relative-path.cpp:19:3
- xorl%eax, %eax
- popq%rbp
- .cfi_def_cfa %rsp, 8
- retq
-.Ltmp1:
-.Lfunc_end0:
- .size main, .Lfunc_end0-main
- .cfi_endproc
-# -- End function
- .type x,@object # @x
- .data
- .globl x
- .p2align2
-x:
- .long 10 # 0xa
- .size x, 4
-
- .type .L__const.main.y,@object# @__const.main.y
- .section.rodata,"a",@progbits
-.L__const.main.y:
- .ascii "abc"
- .size .L__const.main.y, 3
-
- .section.debug_abbrev,"",@progbits
- .byte 1 # Abbreviation Code
- .byte 74 # DW_TAG_skeleton_unit
- .byte 0 # DW_CHILDREN_no
- .byte 16 # DW_AT_stmt_list
- .byte 23 # DW_FORM_sec_offset
- .byte 114 # DW_AT_str_offsets_base
- .byte 23 # DW_FORM_sec_offset
- .byte 27 # DW_AT_comp_dir
- .byte 37 # DW_FORM_strx1
-
[Lldb-commits] [lldb] b241f3c - [LLDB] Use path relative to binary for finding .dwo files.
Author: Caroline Tice
Date: 2021-04-15T14:43:47-07:00
New Revision: b241f3cb292d0ba1ad5a33b3bbd4a8a3a9c909dc
URL:
https://github.com/llvm/llvm-project/commit/b241f3cb292d0ba1ad5a33b3bbd4a8a3a9c909dc
DIFF:
https://github.com/llvm/llvm-project/commit/b241f3cb292d0ba1ad5a33b3bbd4a8a3a9c909dc.diff
LOG: [LLDB] Use path relative to binary for finding .dwo files.
DWARF allows .dwo file paths to be relative rather than absolute. When
they are relative, DWARF uses DW_AT_comp_dir to find the .dwo
file. DW_AT_comp_dir can also be relative, making the entire search
patch for the .dwo file relative. In this case, LLDB currently
searches relative to its current working directory, i.e. the directory
from which the debugger was launched. This is not right, as the
compiler, which generated the relative paths, can have no idea where
the debugger will be launched. The correct thing is to search relative
to the location of the executable binary. That is what this patch
does.
Differential Revision: https://reviews.llvm.org/D97786
Added:
lldb/test/Shell/SymbolFile/DWARF/dwo-relative-path.s
Modified:
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
Removed:
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 3a04f429c7c75..da170383405fb 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -1651,6 +1651,13 @@ SymbolFileDWARF::GetDwoSymbolFileForCompileUnit(
return nullptr;
dwo_file.SetFile(comp_dir, FileSpec::Style::native);
+if (dwo_file.IsRelative()) {
+ // if DW_AT_comp_dir is relative, it should be relative to the location
+ // of the executable, not to the location from which the debugger was
+ // launched.
+ dwo_file.PrependPathComponent(
+ m_objfile_sp->GetFileSpec().GetDirectory().GetStringRef());
+}
FileSystem::Instance().Resolve(dwo_file);
dwo_file.AppendPathComponent(dwo_name);
}
diff --git a/lldb/test/Shell/SymbolFile/DWARF/dwo-relative-path.s
b/lldb/test/Shell/SymbolFile/DWARF/dwo-relative-path.s
new file mode 100644
index 0..cc05434261e4e
--- /dev/null
+++ b/lldb/test/Shell/SymbolFile/DWARF/dwo-relative-path.s
@@ -0,0 +1,417 @@
+# Test to verify LLDB searches for dwos with relative paths relative to the
+# binary location, not relative to LLDB's launch location.
+
+# RUN: llvm-mc --filetype=obj --triple x86_64-pc-linux %s -o %t.o
+# RUN: llvm-objcopy --split-dwo=%T/dwo-relative-path.dwo %t.o
+
+# RUN: cd ../..
+
+# RUN: %lldb %t.o -o "target var x" -b 2>&1 | FileCheck %s
+
+# CHECK: x = 0
+
+ .text
+ .file "dwo-relative-path.cpp"
+ .file 0 "." "dwo-relative-path.cpp" md5
0xadc61d242247514c5d402d62db34b825
+ .globl main# -- Begin function main
+ .p2align4, 0x90
+ .type main,@function
+main: # @main
+.Lfunc_begin0:
+ .loc0 14 0 # dwo-relative-path.cpp:14:0
+ .cfi_startproc
+# %bb.0:# %entry
+ pushq %rbp
+ .cfi_def_cfa_offset 16
+ .cfi_offset %rbp, -16
+ movq%rsp, %rbp
+ .cfi_def_cfa_register %rbp
+ movl$0, -4(%rbp)
+ movl%edi, -8(%rbp)
+ movq%rsi, -16(%rbp)
+.Ltmp0:
+ .loc0 15 8 prologue_end # dwo-relative-path.cpp:15:8
+ movw.L__const.main.y, %ax
+ movw%ax, -19(%rbp)
+ movb.L__const.main.y+2, %al
+ movb%al, -17(%rbp)
+ .loc0 17 14 # dwo-relative-path.cpp:17:14
+ movsbl -19(%rbp), %eax
+ .loc0 17 27 is_stmt 0 # dwo-relative-path.cpp:17:27
+ movsbl -18(%rbp), %ecx
+ .loc0 17 19 # dwo-relative-path.cpp:17:19
+ addl%ecx, %eax
+ .loc0 17 5 # dwo-relative-path.cpp:17:5
+ addlx, %eax
+ movl%eax, x
+ .loc0 19 3 is_stmt 1# dwo-relative-path.cpp:19:3
+ xorl%eax, %eax
+ popq%rbp
+ .cfi_def_cfa %rsp, 8
+ retq
+.Ltmp1:
+.Lfunc_end0:
+ .size main, .Lfunc_end0-main
+ .cfi_endproc
+# -- End function
+ .type x,@object # @x
+ .data
+ .globl x
+ .p2align2
+x:
+ .long 10 # 0xa
+ .size x, 4
+
+ .type .L__const.main.y,@object# @__const.main.y
+ .section.rodata,"a",@progbits
+.L__const.main.y:
+ .ascii "abc"
+ .size .L__const.main.y, 3
+
+ .section.debug_abbrev,"",@progbits
+ .byte 1 # Abbreviation
Re: [Lldb-commits] [PATCH] D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files.
Something went very wrong on the patch upload. This does NOT look like the patch I intended! DO NOT REVIEW THIS UNTIL I CAN UPLOAD THE RIGHT PATCH! -- Caroline cmt...@google.com On Tue, Mar 2, 2021 at 10:53 AM Shoaib Meenai via Phabricator < revi...@reviews.llvm.org> wrote: > smeenai added a comment. > > Is this rebased on main? The LLD for Mach-O changes look like they belong > to a different diff. > > > Repository: > rG LLVM Github Monorepo > > CHANGES SINCE LAST ACTION > https://reviews.llvm.org/D97786/new/ > > https://reviews.llvm.org/D97786 > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
