[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