| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[lldb][AArch64] Fix arm64 hardware breakpoint/watchpoint to arm32 process. (#147198) When debugging arm32 process on arm64 machine, arm64 lldb-server will use NativeRegisterContextLinux_arm, but the server should keep using 64-bit ptrace commands for hardware watchpoint/breakpoint, even when debugging a 32-bit tracee. See: https://github.com/torvalds/linux/commit/5d220ff9420f8b1689805ba2d938bedf9e0860a4 There have been many conditional compilation handling arm32 tracee on arm64, but this one is missed out. To reuse the 64-bit implementation, I separate the shared code from NativeRegisterContextLinux_arm64.cpp to NativeRegisterContextLinux_arm64dbreg.cpp, with other adjustments to share data structures of debug registers. | 1 年前 | |
[lldb][AIX] get host info for AIX (#134354) This PR is in reference to porting LLDB on AIX. Link to discussions on llvm discourse and github: 1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640 2. https://github.com/llvm/llvm-project/issues/101657 The complete changes for porting are present in this draft PR: https://github.com/llvm/llvm-project/pull/102601 - Added changes to make the common host support functions under Host/posix for unix-like system. Also, created the unittests/Host/posix/ to test the hostInfo & support functions for unix-like system. - Added changes to get the host information for AIX. (GetProcessInfo()) (Information like : executable path, arch, process status etc.) | 1 年前 | |
[NFC][lldb][trace] Fix formatting of tracing files Pavel Labath taught me that clang-format sorts headers automatically using llvm's rules, and it's better not to have spaces between So in this diff I'm removing those spaces and formatting them as well. I used clang-format -i to format these files. | 3 年前 | |
[lldb] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 | 3 年前 | |
[lldb] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 | 3 年前 | |
[lldb] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 | 3 年前 | |
[lldb] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 | 3 年前 | |
[lldb] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 | 3 年前 | |
[lldb] Use StringRef::{starts,ends}_with (NFC) This patch replaces uses of StringRef::{starts,ends}with with StringRef::{starts,ends}_with for consistency with std::{string,string_view}::{starts,ends}_with in C++20. I'm planning to deprecate and eventually remove StringRef::{starts,ends}with. | 2 年前 | |
[trace] Migrate uses of operator<<(raw_ostream &OS, const Optional<T> &O) to std::optional | 3 年前 | |
[lldb] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 | 3 年前 | |
[lldb] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 | 3 年前 | |
[lldb][Linux] Fix checking of error values when attach fails (#161673) Relates to #161510 Fixes 6db44e52ce474bbeb66042073a6e3c6c586f78a2 (it's not fixing it, it's just making the error not be an unhandled error) When we fail to attach to a process we see if we can add more information about why it happened: if (status.GetError() == EPERM) { // Depending on the value of ptrace_scope, we can return a different // error that suggests how to fix it. return AddPtraceScopeNote(status.ToError()); } ToError creates a new error value and leaves the one in status unchecked. status's error is ok because it will be checked by Status' destructor. The problem happens in AddPtraceScopeNote. If we take certain return paths, this new error, or the one we get when trying to find the ptrace scope, may be unchecked on destruction when the function returns. To fix this, in AddPtraceScopeNote, consume any errors that we are not going to return. Anything returned will be checked by some caller. Reproducing this failure mode is difficult but it can be faked by calling AddPtraceScopeNote earlier. Which is what I did to prove the concept of the problem. | 9 个月前 | |
[lldb][AIX] get host info for AIX (#134354) This PR is in reference to porting LLDB on AIX. Link to discussions on llvm discourse and github: 1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640 2. https://github.com/llvm/llvm-project/issues/101657 The complete changes for porting are present in this draft PR: https://github.com/llvm/llvm-project/pull/102601 - Added changes to make the common host support functions under Host/posix for unix-like system. Also, created the unittests/Host/posix/ to test the hostInfo & support functions for unix-like system. - Added changes to get the host information for AIX. (GetProcessInfo()) (Information like : executable path, arch, process status etc.) | 1 年前 | |
[lldb] Turn lldb_private::Status into a value type. (#106163) This patch removes all of the Set.* methods from Status. This cleanup is part of a series of patches that make it harder use the anti-pattern of keeping a long-lives Status object around and updating it while dropping any errors it contains on the floor. This patch is largely NFC, the more interesting next steps this enables is to: 1. remove Status.Clear() 2. assert that Status::operator=() never overwrites an error 3. remove Status::operator=() Note that step (2) will bring 90% of the benefits for users, and step (3) will dramatically clean up the error handling code in various places. In the end my goal is to convert all APIs that are of the form ResultTy DoFoo(Status& error) to llvm::Expected<ResultTy> DoFoo() How to read this patch? The interesting changes are in Status.h and Status.cpp, all other changes are mostly perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git grep -l SetErrorString lldb/source) plus the occasional manual cleanup. | 1 年前 | |
[lldb] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 | 3 年前 | |
[lldb][ARM] Port Arm Linux to use NativeRegisterContextDBReg (#152284) Which is also used by AArch64 and LoongArch. To test this, I ran the test suite as usual on Arm and found no new failures, then ran it again with all test programs compiled with -mthumb. This means the binaries will be entirely Thumb code. Finally I tested it on AArch64, but this is mostly a build test, as I did not run the entire test suite compiled to AArch32. Prior to this change, these tests failed with -mthumb: Failed Tests (14): lldb-api :: commands/process/reverse-continue/TestReverseContinue.py lldb-api :: functionalities/breakpoint/breakpoint_by_line_and_column/TestBreakpointByLineAndColumn.py lldb-api :: functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py lldb-api :: functionalities/reverse-execution/TestReverseContinueBreakpoints.py lldb-api :: functionalities/reverse-execution/TestReverseContinueWatchpoints.py lldb-api :: functionalities/tail_call_frames/disambiguate_call_site/TestDisambiguateCallSite.py lldb-api :: functionalities/tail_call_frames/disambiguate_paths_to_common_sink/TestDisambiguatePathsToCommonSink.py lldb-api :: functionalities/tail_call_frames/disambiguate_tail_call_seq/TestDisambiguateTailCallSeq.py lldb-api :: functionalities/tail_call_frames/inlining_and_tail_calls/TestInliningAndTailCalls.py lldb-api :: functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py lldb-api :: functionalities/tail_call_frames/thread_step_out_message/TestArtificialFrameStepOutMessage.py lldb-api :: functionalities/thread/jump/TestThreadJump.py lldb-api :: lang/c/vla/TestVLA.py lldb-api :: linux/sepdebugsymlink/TestTargetSymbolsSepDebugSymlink.py After this change, no new failures occurred. So I am confident it is correct / as bad as it always was. Looking at those failures, it's a few things: * Something in the reverse execution wrapper that I can't figure out, but is likely nothing to do with the real breakpoints. * The inability to tail call when building thumb code, because the call goes via. a veneer that might do a mode switch. * Assumptions about source locations being in specific places. None of which are issues I feel like need fixing before doing this port. I suspect there is redundant code in this, particularly aligning addresses. I've not made an effort to remove it because A: I'm scared to break Thumb support because it's not commonly used and B: it may be there to handle clients other than LLDB, which don't align breakpoint addresses before requesting them. | 11 个月前 | |
[lldb][ARM] Port Arm Linux to use NativeRegisterContextDBReg (#152284) Which is also used by AArch64 and LoongArch. To test this, I ran the test suite as usual on Arm and found no new failures, then ran it again with all test programs compiled with -mthumb. This means the binaries will be entirely Thumb code. Finally I tested it on AArch64, but this is mostly a build test, as I did not run the entire test suite compiled to AArch32. Prior to this change, these tests failed with -mthumb: Failed Tests (14): lldb-api :: commands/process/reverse-continue/TestReverseContinue.py lldb-api :: functionalities/breakpoint/breakpoint_by_line_and_column/TestBreakpointByLineAndColumn.py lldb-api :: functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py lldb-api :: functionalities/reverse-execution/TestReverseContinueBreakpoints.py lldb-api :: functionalities/reverse-execution/TestReverseContinueWatchpoints.py lldb-api :: functionalities/tail_call_frames/disambiguate_call_site/TestDisambiguateCallSite.py lldb-api :: functionalities/tail_call_frames/disambiguate_paths_to_common_sink/TestDisambiguatePathsToCommonSink.py lldb-api :: functionalities/tail_call_frames/disambiguate_tail_call_seq/TestDisambiguateTailCallSeq.py lldb-api :: functionalities/tail_call_frames/inlining_and_tail_calls/TestInliningAndTailCalls.py lldb-api :: functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py lldb-api :: functionalities/tail_call_frames/thread_step_out_message/TestArtificialFrameStepOutMessage.py lldb-api :: functionalities/thread/jump/TestThreadJump.py lldb-api :: lang/c/vla/TestVLA.py lldb-api :: linux/sepdebugsymlink/TestTargetSymbolsSepDebugSymlink.py After this change, no new failures occurred. So I am confident it is correct / as bad as it always was. Looking at those failures, it's a few things: * Something in the reverse execution wrapper that I can't figure out, but is likely nothing to do with the real breakpoints. * The inability to tail call when building thumb code, because the call goes via. a veneer that might do a mode switch. * Assumptions about source locations being in specific places. None of which are issues I feel like need fixing before doing this port. I suspect there is redundant code in this, particularly aligning addresses. I've not made an effort to remove it because A: I'm scared to break Thumb support because it's not commonly used and B: it may be there to handle clients other than LLDB, which don't align breakpoint addresses before requesting them. | 11 个月前 | |
[lldb][AArch64] Fix arm64 hardware breakpoint/watchpoint to arm32 process. (#147198) When debugging arm32 process on arm64 machine, arm64 lldb-server will use NativeRegisterContextLinux_arm, but the server should keep using 64-bit ptrace commands for hardware watchpoint/breakpoint, even when debugging a 32-bit tracee. See: https://github.com/torvalds/linux/commit/5d220ff9420f8b1689805ba2d938bedf9e0860a4 There have been many conditional compilation handling arm32 tracee on arm64, but this one is missed out. To reuse the 64-bit implementation, I separate the shared code from NativeRegisterContextLinux_arm64.cpp to NativeRegisterContextLinux_arm64dbreg.cpp, with other adjustments to share data structures of debug registers. | 1 年前 | |
[lldb][AArch64] Add Guarded Control Stack registers (#123720) The Guarded Control Stack extension implements a shadow stack and the Linux kernel provides access to 3 registers for it via ptrace. struct user_gcs { __u64 features_enabled; __u64 features_locked; __u64 gcspr_el0; }; This commit adds support for reading those from a live process. The first 2 are pseudo registers based on the real control register and the 3rd is a real register. This is the stack pointer for the guarded stack. I have added a "gcs_" prefix to the "features" registers so that they have a clear name when shown individually. Also this means they will tab complete from "gcs", and be next to gcspr_el0 in any sorted lists of registers. Guarded Control Stack Registers: gcs_features_enabled = 0x0000000000000000 gcs_features_locked = 0x0000000000000000 gcspr_el0 = 0x0000000000000000 Testing is more of the usual, where possible I'm writing a register then doing something in the program to confirm the value was actually sent to ptrace. | 1 年前 | |
[lldb][AArch64] Fix arm64 hardware breakpoint/watchpoint to arm32 process. (#147198) When debugging arm32 process on arm64 machine, arm64 lldb-server will use NativeRegisterContextLinux_arm, but the server should keep using 64-bit ptrace commands for hardware watchpoint/breakpoint, even when debugging a 32-bit tracee. See: https://github.com/torvalds/linux/commit/5d220ff9420f8b1689805ba2d938bedf9e0860a4 There have been many conditional compilation handling arm32 tracee on arm64, but this one is missed out. To reuse the 64-bit implementation, I separate the shared code from NativeRegisterContextLinux_arm64.cpp to NativeRegisterContextLinux_arm64dbreg.cpp, with other adjustments to share data structures of debug registers. | 1 年前 | |
[lldb][AArch64] Fix arm64 hardware breakpoint/watchpoint to arm32 process. (#147198) When debugging arm32 process on arm64 machine, arm64 lldb-server will use NativeRegisterContextLinux_arm, but the server should keep using 64-bit ptrace commands for hardware watchpoint/breakpoint, even when debugging a 32-bit tracee. See: https://github.com/torvalds/linux/commit/5d220ff9420f8b1689805ba2d938bedf9e0860a4 There have been many conditional compilation handling arm32 tracee on arm64, but this one is missed out. To reuse the 64-bit implementation, I separate the shared code from NativeRegisterContextLinux_arm64.cpp to NativeRegisterContextLinux_arm64dbreg.cpp, with other adjustments to share data structures of debug registers. | 1 年前 | |
[LLDB][LoongArch] Extend the maximum number of watchpoints (#126204) The maximum number of load/store watchpoints and fetch instruction watchpoints is 14 each according to LoongArch Reference Manual [1], so extend the maximum number of watchpoints from 8 to 14 for ptrace. A new struct user_watch_state_v2 was added into uapi in the related kernel commit 531936dee53e ("LoongArch: Extend the maximum number of watchpoints") [2], but there may be no struct user_watch_state_v2 in the system header in time. In order to avoid undefined or redefined error, just add a new struct loongarch_user_watch_state in LLDB which is same with the uapi struct user_watch_state_v2, then replace the current user_watch_state with loongarch_user_watch_state. As far as I can tell, the only users for this struct in the userspace are GDB and LLDB, there are no any problems of software compatibility between the application and kernel according to the analysis. The compatibility problem has been considered while developing and testing. When the applications in the userspace get watchpoint state, the length will be specified which is no bigger than the sizeof struct user_watch_state or user_watch_state_v2, the actual length is assigned as the minimal value of the application and kernel in the generic code of ptrace: kernel/ptrace.c: ptrace_regset(): kiov->iov_len = min(kiov->iov_len, (__kernel_size_t) (regset->n * regset->size)); if (req == PTRACE_GETREGSET) return copy_regset_to_user(task, view, regset_no, 0, kiov->iov_len, kiov->iov_base); else return copy_regset_from_user(task, view, regset_no, 0, kiov->iov_len, kiov->iov_base); For example, there are four kind of combinations, all of them work well. (1) "older kernel + older app", the actual length is 8+(8+8+4+4)*8=200; (2) "newer kernel + newer app", the actual length is 8+(8+8+4+4)*14=344; (3) "older kernel + newer app", the actual length is 8+(8+8+4+4)*8=200; (4) "newer kernel + older app", the actual length is 8+(8+8+4+4)*8=200. [1] https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=531936dee53e Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> | 1 年前 | |
[LLDB][LoongArch] Add LSX and LASX register definitions and operations With this patch, vector registers can be read and written when debugging a live process. Note: We currently assume that all LoongArch64 processors include the LSX and LASX extensions. To add test cases, the following modifications were also made: lldb/packages/Python/lldbsuite/test/lldbtest.py lldb/packages/Python/lldbsuite/test/make/Makefile.rules Reviewed By: DavidSpickett, SixWeining Pull Request: https://github.com/llvm/llvm-project/pull/120664 | 1 年前 | |
[lldb] Turn lldb_private::Status into a value type. (#106163) This patch removes all of the Set.* methods from Status. This cleanup is part of a series of patches that make it harder use the anti-pattern of keeping a long-lives Status object around and updating it while dropping any errors it contains on the floor. This patch is largely NFC, the more interesting next steps this enables is to: 1. remove Status.Clear() 2. assert that Status::operator=() never overwrites an error 3. remove Status::operator=() Note that step (2) will bring 90% of the benefits for users, and step (3) will dramatically clean up the error handling code in various places. In the end my goal is to convert all APIs that are of the form ResultTy DoFoo(Status& error) to llvm::Expected<ResultTy> DoFoo() How to read this patch? The interesting changes are in Status.h and Status.cpp, all other changes are mostly perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git grep -l SetErrorString lldb/source) plus the occasional manual cleanup. | 1 年前 | |
[lldb] Fix m_hwp_regs size for ppc64le (PR54520) The size of the m_hwp_regs array should match the default value of m_max_hwp_supported. This ensures that no out-of-bounds accesses occur, even if the array is accessed prior to a call to ReadHardwareDebugInfo(). Fixes https://github.com/llvm/llvm-project/issues/54520, see also there for additional background. Differential Revision: https://reviews.llvm.org/D136144 | 3 年前 | |
[lldb][RISCV] Support optionally disabled FPR for riscv64 (#104547) The PR adds the support optionally enabled/disabled FP-registers to LLDB RegisterInfoPOSIX_riscv64. This situation might take place for RISC-V builds having no FP-registers, like RV64IMAC or RV64IMACV. To aim this, patch adds opt_regsets flags mechanism. It re-works RegisterInfo class to work with flexibly allocated (depending on opt_regsets flag) m_register_sets and m_register_infos vectors instead of statically defined structures. The registration of regsets is being arranged by m_per_regset_regnum_range map. The patch flows are spread to NativeRegisterContextLinux_riscv64 and RegisterContextCorePOSIX_riscv64 classes, that were tested on: - x86_64 host working with coredumps - RV64GC and RV64IMAC targets working with coredumps and natively in run-time with binaries EmulateInstructionRISCV is out of scope of this patch, and its behavior did not change, using maximum set of registers. According testcase built for RV64IMAC (no-FPR) was added to TestLinuxCore.py. | 1 年前 | |
[lldb][RISCV] Support optionally disabled FPR for riscv64 (#104547) The PR adds the support optionally enabled/disabled FP-registers to LLDB RegisterInfoPOSIX_riscv64. This situation might take place for RISC-V builds having no FP-registers, like RV64IMAC or RV64IMACV. To aim this, patch adds opt_regsets flags mechanism. It re-works RegisterInfo class to work with flexibly allocated (depending on opt_regsets flag) m_register_sets and m_register_infos vectors instead of statically defined structures. The registration of regsets is being arranged by m_per_regset_regnum_range map. The patch flows are spread to NativeRegisterContextLinux_riscv64 and RegisterContextCorePOSIX_riscv64 classes, that were tested on: - x86_64 host working with coredumps - RV64GC and RV64IMAC targets working with coredumps and natively in run-time with binaries EmulateInstructionRISCV is out of scope of this patch, and its behavior did not change, using maximum set of registers. According testcase built for RV64IMAC (no-FPR) was added to TestLinuxCore.py. | 1 年前 | |
[lldb] Turn lldb_private::Status into a value type. (#106163) This patch removes all of the Set.* methods from Status. This cleanup is part of a series of patches that make it harder use the anti-pattern of keeping a long-lives Status object around and updating it while dropping any errors it contains on the floor. This patch is largely NFC, the more interesting next steps this enables is to: 1. remove Status.Clear() 2. assert that Status::operator=() never overwrites an error 3. remove Status::operator=() Note that step (2) will bring 90% of the benefits for users, and step (3) will dramatically clean up the error handling code in various places. In the end my goal is to convert all APIs that are of the form ResultTy DoFoo(Status& error) to llvm::Expected<ResultTy> DoFoo() How to read this patch? The interesting changes are in Status.h and Status.cpp, all other changes are mostly perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git grep -l SetErrorString lldb/source) plus the occasional manual cleanup. | 1 年前 | |
[lldb] Update the NativeRegisterContext to take a WritableMemoryBuffer | 4 年前 | |
[lldb] Turn lldb_private::Status into a value type. (#106163) This patch removes all of the Set.* methods from Status. This cleanup is part of a series of patches that make it harder use the anti-pattern of keeping a long-lives Status object around and updating it while dropping any errors it contains on the floor. This patch is largely NFC, the more interesting next steps this enables is to: 1. remove Status.Clear() 2. assert that Status::operator=() never overwrites an error 3. remove Status::operator=() Note that step (2) will bring 90% of the benefits for users, and step (3) will dramatically clean up the error handling code in various places. In the end my goal is to convert all APIs that are of the form ResultTy DoFoo(Status& error) to llvm::Expected<ResultTy> DoFoo() How to read this patch? The interesting changes are in Status.h and Status.cpp, all other changes are mostly perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git grep -l SetErrorString lldb/source) plus the occasional manual cleanup. | 1 年前 | |
[lldb][x86_64] Support fs_base/gs_base register in Linux Summary: [lldb][x86_64] This patch adds fs_base/gs_base support for Linux x86_64. Originally, I plan to split the diff into two parts, one to refactoring lldb_xxx_x86_64 => x86_64::lldb_xxx across code base and the other one for adding fs_base/gs_base, but it turns out to be a non-trivial effort to split and very error prone so I decided to keep a single diff to get feedback. GDB supports fs_base/gs_base registers while LLDB does not. Since both linux coredump note section and ptrace supports them it is a missing feature. For context, this is a required feature to support getting pthread pointer on linux from both live and dump debugging. See thread below for details: https://discourse.llvm.org/t/how-to-get-pthread-pointer-from-lldb/70542/2?u=jeffreytan81 Implementation wise, we have initially tried #ifdef approach to reuse the code but it is introducing very tricky bugs and proves hard to maintain. Instead the diff completely separates the registers between x86_64 and x86_64_with_base so that non-linux related implementations can use x86_64 registers while linux uses x86_64_with_base. Here are the list of changes done in the patch: * Registers in lldb-x86-register-enums.h are separated into two: x86_64 and x86_64_with_base * fs_base/gs_base are added into x86_64_with_base * All linux files are change to use x86_64::lldb_xxx => x86_64_with_base::lldb_xxx * Support linux elf-core: * A new RegisterContextLinuxCore_x86_64 class is added for ThreadElfCore * RegisterContextLinuxCore_x86_64 overrides and uses its own register set supports fs_base/gs_base * RegisterInfos_x86_64_with_base/RegisterInfos_x86_64_with_base_shared ared added to provide g_contained_XXX/g_invalidate_XXX and RegInfo related code sharing. * RegisterContextPOSIX_x86 ::m_gpr_x86_64 seems to be unused so I removed it. * NativeRegisterContextDBReg_x86::GetDR() is overridden in NativeRegisterContextLinux_x86_64 to make watchpoint work. Reviewers:clayborg,labath,jingham,jdoerfert,JDevlieghere,kusmour,GeorgeHuyubo Subscribers: Tasks: Tags: Differential Revision: https://reviews.llvm.org/D155256 | 2 年前 | |
Reapply "[lldb] Implement basic support for reverse-continue (#125242)" (again) (#128156) This reverts commit https://github.com/llvm/llvm-project/commit/87b7f63a117c340a6d9ca47959335fd7ef6c7ad2, reapplying https://github.com/llvm/llvm-project/commit/7e66cf74fb4e6a103f923e34700a7b6f20ac2a9b with a small (and probably temporary) change to generate more debug info to help with diagnosing buildbot issues. | 1 年前 | |
Reland "[lldb] Refactor CrashReason" This reverts commit 71c4d186f1cf247f1aa45f4fd1b38f350b68d123. The reinterpret casts were not needed. | 3 年前 | |
[lldb][AIX] get host info for AIX (#134354) This PR is in reference to porting LLDB on AIX. Link to discussions on llvm discourse and github: 1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640 2. https://github.com/llvm/llvm-project/issues/101657 The complete changes for porting are present in this draft PR: https://github.com/llvm/llvm-project/pull/102601 - Added changes to make the common host support functions under Host/posix for unix-like system. Also, created the unittests/Host/posix/ to test the hostInfo & support functions for unix-like system. - Added changes to get the host information for AIX. (GetProcessInfo()) (Information like : executable path, arch, process status etc.) | 1 年前 | |
[lldb] Replace None with std::nullopt in comments (NFC) This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 | 3 年前 | |
[lldb] Fix SIGSEGV in GetPtraceScope() in Procfs.cpp (#142224) # Symptom We have seen SIGSEGV like this: `` * thread #1, name = 'lldb-server', stop reason = SIGSEGV frame #0: 0x00007f39e529c993 libc.so.6__pthread_kill_internal(signo=11, threadid=<unavailable>) at pthread_kill.c:46:37 ... * frame #5: 0x000056027c94fe48 lldb-serverlldb_private::process_linux::GetPtraceScope() + 72 frame #6: 0x000056027c92f94f lldb-serverlldb_private::process_linux::NativeProcessLinux::Attach(int) + 1087 ... `` See [full stack trace](https://pastebin.com/X0d6QhYj). This happens on Linux where LLDB doesn't have access to /proc/sys/kernel/yama/ptrace_scope. A similar error (an unchecked Error) can be reproduced by running the newly added unit test without the fix. See the "Test" section below. # Root cause GetPtraceScope() ([code](https://github.com/llvm/llvm-project/blob/328f40f408c218f25695ea42c844e43bef38660b/lldb/source/Plugins/Process/Linux/Procfs.cpp#L77)) has the following if statement: llvm::Expected<int> lldb_private::process_linux::GetPtraceScope() { ErrorOr<std::unique_ptr<MemoryBuffer>> ptrace_scope_file = getProcFile("sys/kernel/yama/ptrace_scope"); if (!*ptrace_scope_file) return errorCodeToError(ptrace_scope_file.getError()); ... } The intention of the if statement is to check whether the ptrace_scope_file is an Error or not, and return the error if it is. However, the operator* of ErrorOr returns the value that is stored (which is a std::unique_ptr<MemoryBuffer>), so what the if condition actually do is to check if the unique pointer is non-null. Note that the method ErrorOr::getStorage() ([called by](https://github.com/llvm/llvm-project/blob/328f40f408c218f25695ea42c844e43bef38660b/llvm/include/llvm/Support/ErrorOr.h#L162-L164) ErrorOr::operator *) **does** assert on whether or not HasError has been set (see [ErrorOr.h](https://github.com/llvm/llvm-project/blob/328f40f408c218f25695ea42c844e43bef38660b/llvm/include/llvm/Support/ErrorOr.h#L235-L243)). However, it seems this wasn't executed, probably because the LLDB was a release build. # Fix The fix is simply remove the * in the said if` statement. | 1 年前 | |
[Linux] Add kernel.yama.ptrace_scope note when ptrace fails to attach. A common reason for LLDB failing to attach to an already-running process on Linux is the Yama security module: https://www.kernel.org/doc/Documentation/security/Yama.txt. This patch adds an explaination and suggested fix when it detects that case happening. This was previously proposed in D106226, but hasn't been updated in a while. The last request was to put the check in a target-specific location, which is the approach this patch takes. I believe Yama only exists on Linux, so it's put in that package. This has no end-to-end test because I'm not sure how to set ptrace_scope in a test environment -- if there are suggestions on how to do that, I'd be happy to add it. (Also, setting it to 3 is comically irreversible). I tested this locally. Reviewed By: DavidSpickett, labath Differential Revision: https://reviews.llvm.org/D144904 | 3 年前 | |
[lldb] Convert POSIXLog to use the new API | 4 年前 | |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636 | 7 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 11 个月前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 4 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 7 年前 |