| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb] Use llvm::rotr (NFC) | 3 年前 | |
[lldb][FreeBSD] Add Auxv numbers for HWCAP3 and HWCAP4 (#151152) These entries serve the same purpose as the Linux HWCAPs but have been assigned different numbers as FreeBSD had already used the Linux ones. The numbers were assigned in: https://github.com/freebsd/freebsd-src/commit/85007872d1227006adf2ce119fe30de856cbe12d In theory we can read these for the purposes of register field detection, even on earlier versions of FreeBSD. As the aux data is a key-value structure, we simply won't find the new numbers on older systems. However, FreeBSD has not defined any feature bits for HWACP3 and 4. It is likley that they will match the Linux feature bits, but I have no proof of that yet. For instance, FEAT_MTE_STORE_ONLY is indicated by a HWCAP3 feature bit on Linux. FreeBSD does not support this feature at all yet. So for now, these values exist for future use and are not used for register field detection on FreeBSD. | 1 年前 | |
[lldb][FreeBSD] Add Auxv numbers for HWCAP3 and HWCAP4 (#151152) These entries serve the same purpose as the Linux HWCAPs but have been assigned different numbers as FreeBSD had already used the Linux ones. The numbers were assigned in: https://github.com/freebsd/freebsd-src/commit/85007872d1227006adf2ce119fe30de856cbe12d In theory we can read these for the purposes of register field detection, even on earlier versions of FreeBSD. As the aux data is a key-value structure, we simply won't find the new numbers on older systems. However, FreeBSD has not defined any feature bits for HWACP3 and 4. It is likley that they will match the Linux feature bits, but I have no proof of that yet. For instance, FEAT_MTE_STORE_ONLY is indicated by a HWCAP3 feature bit on Linux. FreeBSD does not support this feature at all yet. So for now, these values exist for future use and are not used for register field detection on FreeBSD. | 1 年前 | |
[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] Fix build on older FreeBSD Commit 392d9eb03af5a1adac66a86939351b22b3e73495 added a dependency on FPE_FLTIDO which was only defined in FreeBSD main on May 19, 2022 and is not in all supported releases. Just define it if it's missing as we could use a debugger compiled on an older system to debug a newer one. Reviewed by: DavidSpickett, emaste, dim Differential Revision: https://reviews.llvm.org/D147300 | 3 年前 | |
Revert "[lldb] Move UnixSignals creation into Platform plugins" This reverts commit ee232506b870ce5282cc4da5ca493d41d361feb3. As discussed in https://reviews.llvm.org/D146668 we'll find another way forward. | 3 年前 | |
[lldb] Do not stop the process on SIGWINCH by default. (#163182) SIGWINCH is sent when the terminal window size changes.. Most people debugging do not want the process on this signal. When using lldb-dap, the user may be using an integrated terminal and may resize the pane/window mulitple times when debugging. this causes the signal to be sent multiple times. It gets in the way. The process ignores this signal by default | 9 个月前 | |
Revert "[lldb] Move UnixSignals creation into Platform plugins" This reverts commit ee232506b870ce5282cc4da5ca493d41d361feb3. As discussed in https://reviews.llvm.org/D146668 we'll find another way forward. | 3 年前 | |
[lldb] Fix source line annotations for libsanitizers traces (#154247) When providing allocation and deallocation traces, the ASan compiler-rt runtime already provides call addresses ( TracePCType::Calls). On Darwin, system sanitizers (libsanitizers) provides return address. It also discards a few non-user frames at the top of the stack, because these internal libmalloc/libsanitizers stack frames do not provide any value when diagnosing memory errors. Introduce and add handling for TracePCType::ReturnsNoZerothFrame to cover this case and enable libsanitizers traces line-level testing. rdar://157596927 --- Commit 1 is a mechanical refactoring to introduce and adopt TracePCType enum to replace pcs_are_call_addresses bool. It preserve the current behavior: pcs_are_call_addresses: false -> TracePCType::Returns (default) true -> TracePCType::Calls Best reviewed commit by commit. | 11 个月前 | |
[lldb] Fix source line annotations for libsanitizers traces (#154247) When providing allocation and deallocation traces, the ASan compiler-rt runtime already provides call addresses ( TracePCType::Calls). On Darwin, system sanitizers (libsanitizers) provides return address. It also discards a few non-user frames at the top of the stack, because these internal libmalloc/libsanitizers stack frames do not provide any value when diagnosing memory errors. Introduce and add handling for TracePCType::ReturnsNoZerothFrame to cover this case and enable libsanitizers traces line-level testing. rdar://157596927 --- Commit 1 is a mechanical refactoring to introduce and adopt TracePCType enum to replace pcs_are_call_addresses bool. It preserve the current behavior: pcs_are_call_addresses: false -> TracePCType::Returns (default) true -> TracePCType::Calls Best reviewed commit by commit. | 11 个月前 | |
[lldb] Add unreachable after fully covered switches, avoid GCC warnings. NFC. (#159327) This avoids the following kind of warning with GCC: warning: control reaches end of non-void function [-Wreturn-type] | 10 个月前 | |
[lldb] Fix source line annotations for libsanitizers traces (#154247) When providing allocation and deallocation traces, the ASan compiler-rt runtime already provides call addresses ( TracePCType::Calls). On Darwin, system sanitizers (libsanitizers) provides return address. It also discards a few non-user frames at the top of the stack, because these internal libmalloc/libsanitizers stack frames do not provide any value when diagnosing memory errors. Introduce and add handling for TracePCType::ReturnsNoZerothFrame to cover this case and enable libsanitizers traces line-level testing. rdar://157596927 --- Commit 1 is a mechanical refactoring to introduce and adopt TracePCType enum to replace pcs_are_call_addresses bool. It preserve the current behavior: pcs_are_call_addresses: false -> TracePCType::Returns (default) true -> TracePCType::Calls Best reviewed commit by commit. | 11 个月前 | |
[lldb] Add SymbolContext::GetFunctionOrSymbolAddress (#123340) Many uses of SC::GetAddressRange were not interested in the range, but in the address of the function/symbol contained inside the symbol context. They were getting that by calling the GetBaseAddress on the returned range, which worked well enough so far, but isn't compatible with discontinuous functions, whose address (entry point) may not be the lowest address in the range. To resolve this problem, this PR creates a new function whose purpose is return the address of the function or symbol inside the symbol context. It also changes all of the callers of GetAddressRange which do not actually care about the range to call this function instead. | 1 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb][AArch64] Add SME's Array Storage (ZA) register Note: This requires later commits for ZA to function properly, it is split for ease of review. Testing is also in a later patch. The "Matrix" part of the Scalable Matrix Extension is a new register "ZA". You can think of this as a square matrix made up of scalable rows, where each row is one scalable vector long. However it is not made of the existing scalable vector registers, it is its own register. Meaning that the size of ZA is the vector length in bytes * the vector length in bytes. https://developer.arm.com/documentation/ddi0616/latest/ It uses the streaming vector length, even when streaming mode itself is not active. For this reason, it's register data header always includes the streaming vector length. Due to it's size I've changed kMaxRegisterByteSize to the maximum possible ZA size and kTypicalRegisterByteSize will be the maximum possible scalable vector size. Therefore ZA transactions will cause heap allocations, and non ZA registers will perform exactly as before. ZA can be enabled and disabled independently of streaming mode. The way this works in ptrace is different to SVE versus streaming SVE. Writing NT_ARM_ZA without register data disables ZA, writing NT_ARM_ZA with register data enables ZA (LLDB will only support the latter, and only because it's convenient for us to do so). https://kernel.org/doc/html/v6.2/arm64/sme.html LLDB does not handle registers that can appear and dissappear at runtime. Rather than add complexity to implement that, LLDB will show a block of 0s when ZA is disabled. The alternative is not only updating the vector lengths every stop, but every register definition. It's possible but I'm not sure it's worth pursuing. Users should refer to the SVCR register (added in later patches) for the final word on whether ZA is active or not. Writing to "VG" during streaming mode will change the size of the streaming sve registers and ZA. LLDB will not attempt to preserve register values in this case, we'll just read back the undefined content the kernel shows. This is in line with, as stated, the kernel ABIs and the prospective software ABIs look like. ZA is defined as a vector of size SVL*SVL, so the display in lldb is very basic. A giant block of values. This is no worse than SVE, just larger. There is scope to improve this but that can wait until we see some use cases. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D159502 | 2 年前 | |
[lldb][Linux] Mark memory regions used for shadow stacks (#117861) This is intended for use with Arm's Guarded Control Stack extension (GCS). Which reuses some existing shadow stack support in Linux. It should also work with the x86 equivalent. A "ss" flag is added to the "VmFlags" line of shadow stack memory regions in /proc/<pid>/smaps. To keep the naming generic I've called it shadow stack instead of guarded control stack. Also the wording is "shadow stack: yes" because the shadow stack region is just where it's stored. It's enabled for the whole process or it isn't. As opposed to memory tagging which can be enabled per region, so "memory tagging: enabled" fits better for that. I've added a test case that is also intended to be the start of a set of tests for GCS. This should help me avoid duplicating the inline assembly needed. Note that no special compiler support is needed for the test. However, for the intial enabling of GCS (assuming the libc isn't doing it) we do need to use an inline assembly version of prctl. This is because as soon as you enable GCS, all returns are checked against the GCS. If the GCS is empty, the program will fault. In other words, you can never return from the function that enabled GCS, unless you push values onto it (which is possible but not needed here). So you cannot use the libc's prctl wrapper for this reason. You can use that wrapper for anything else, as we do to check if GCS is enabled. | 1 年前 | |
[lldb][AArch64/Linux] Show memory tagged memory regions This extends the "memory region" command to show tagged regions on AArch64 Linux when the MTE extension is enabled. (lldb) memory region the_page [0x0000fffff7ff8000-0x0000fffff7ff9000) rw- memory tagging: enabled This is done by adding an optional "flags" field to the qMemoryRegion packet. The only supported flag is "mt" but this can be extended. This "mt" flag is read from /proc/{pid}/smaps on Linux, other platforms will leave out the "flags" field. Where this "mt" flag is received "memory region" will show that it is enabled. If it is not or the target doesn't support memory tagging, the line is not shown. (since majority of the time tagging will not be enabled) Testing is added for the existing /proc/{pid}/maps parsing and the new smaps parsing. Minidump parsing has been updated where needed, though it only uses maps not smaps. Target specific tests can be run with QEMU and I have added MTE flags to the existing helper scripts. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D87442 | 5 年前 | |
[lldb] Do not stop the process on SIGWINCH by default. (#163182) SIGWINCH is sent when the terminal window size changes.. Most people debugging do not want the process on this signal. When using lldb-dap, the user may be using an integrated terminal and may resize the pane/window mulitple times when debugging. this causes the signal to be sent multiple times. It gets in the way. The process ignores this signal by default | 9 个月前 | |
Revert "[lldb] Move UnixSignals creation into Platform plugins" This reverts commit ee232506b870ce5282cc4da5ca493d41d361feb3. As discussed in https://reviews.llvm.org/D146668 we'll find another way forward. | 3 年前 | |
[lldb][AArch64] Handle core file tag segments missing tag data (#145338) In the same way that memory regions may be known from a core file but not readable, tag segments can also have no content. For example: $ readelf --segments core <...> Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align <...> LOAD 0x0000000000002000 0x0000ffff93899000 0x0000000000000000 0x0000000000000000 0x0000000000001000 RW 0x1000 <...> LOPROC+0x2 0x0000000000008000 0x0000ffff93899000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0 This happens if you have a restricted coredump filter or size limit. The area of virtual memory this segment covers is 0x1000, or 4096 bytes aka one tagged page. It's FileSiz would normally be 0x80. Tags are packed 2 per byte and granules are 16 bytes. 4096 / 16 / 2 = 128 or 0x80. But here it has no data, and in theory a corrupt file might have some data but not all. This triggered an assert in UnpackTagsFromCoreFileSegment and crashed lldb. To fix this I have made UnpackTagsFromCoreFileSegment return an expected and returned an error in this case instead of asserting. This will be seen by the user, as shown in the added API test. | 1 年前 | |
[lldb][AArch64] Handle core file tag segments missing tag data (#145338) In the same way that memory regions may be known from a core file but not readable, tag segments can also have no content. For example: $ readelf --segments core <...> Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align <...> LOAD 0x0000000000002000 0x0000ffff93899000 0x0000000000000000 0x0000000000000000 0x0000000000001000 RW 0x1000 <...> LOPROC+0x2 0x0000000000008000 0x0000ffff93899000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0 This happens if you have a restricted coredump filter or size limit. The area of virtual memory this segment covers is 0x1000, or 4096 bytes aka one tagged page. It's FileSiz would normally be 0x80. Tags are packed 2 per byte and granules are 16 bytes. 4096 / 16 / 2 = 128 or 0x80. But here it has no data, and in theory a corrupt file might have some data but not all. This triggered an assert in UnpackTagsFromCoreFileSegment and crashed lldb. To fix this I have made UnpackTagsFromCoreFileSegment return an expected and returned an error in this case instead of asserting. This will be seen by the user, as shown in the added API test. | 1 年前 | |
[lldb][RISCV] fix LR/SC atomic sequence handling in lldb-server (#146072) lldb-server had limited support for single-stepping through the lr/sc atomic sequence. This patch enhances that support for all possible atomic sequences. The previous version contained an incorrect regex pattern in the test, causing the riscv-specific test to run on other platforms. This reland fixes the regex (see lldb/test/API/riscv/step/TestSoftwareStep.py) | 1 年前 | |
[lldb][RISCV] fix LR/SC atomic sequence handling in lldb-server (#146072) lldb-server had limited support for single-stepping through the lr/sc atomic sequence. This patch enhances that support for all possible atomic sequences. The previous version contained an incorrect regex pattern in the test, causing the riscv-specific test to run on other platforms. This reland fixes the regex (see lldb/test/API/riscv/step/TestSoftwareStep.py) | 1 年前 | |
[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][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][Process/Utility] Introduce NativeRegisterContextDBReg class Since the setup of debug registers for AArch64 and LoongArch is similar, we extracted the shared logic from Class: NativeRegisterContextDBReg_arm64 into a new Class: NativeRegisterContextDBReg. This will simplify the subsequent implementation of hardware breakpoints and watchpoints on LoongArch. Reviewed By: DavidSpickett Pull Request: https://github.com/llvm/llvm-project/pull/118043 | 1 年前 | |
[LLDB][Process/Utility] Introduce NativeRegisterContextDBReg class Since the setup of debug registers for AArch64 and LoongArch is similar, we extracted the shared logic from Class: NativeRegisterContextDBReg_arm64 into a new Class: NativeRegisterContextDBReg. This will simplify the subsequent implementation of hardware breakpoints and watchpoints on LoongArch. Reviewed By: DavidSpickett Pull Request: https://github.com/llvm/llvm-project/pull/118043 | 1 年前 | |
[lldb][Process] Introduce LoongArch64 hw break/watchpoint support This patch adds support for setting/clearing hardware watchpoints and breakpoints on LoongArch 64-bit hardware. Refer to the following document for the hw break/watchpoint: https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints Fix Failed Tests: lldb-shell :: Subprocess/clone-follow-child-wp.test lldb-shell :: Subprocess/clone-follow-parent-wp.test lldb-shell :: Subprocess/fork-follow-child-wp.test lldb-shell :: Subprocess/fork-follow-parent-wp.test lldb-shell :: Subprocess/vfork-follow-child-wp.test lldb-shell :: Subprocess/vfork-follow-parent-wp.test lldb-shell :: Watchpoint/ExpressionLanguage.test Depends on: #118043 Reviewed By: SixWeining Pull Request: https://github.com/llvm/llvm-project/pull/118770 | 1 年前 | |
[lldb][Process] Introduce LoongArch64 hw break/watchpoint support This patch adds support for setting/clearing hardware watchpoints and breakpoints on LoongArch 64-bit hardware. Refer to the following document for the hw break/watchpoint: https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints Fix Failed Tests: lldb-shell :: Subprocess/clone-follow-child-wp.test lldb-shell :: Subprocess/clone-follow-parent-wp.test lldb-shell :: Subprocess/fork-follow-child-wp.test lldb-shell :: Subprocess/fork-follow-parent-wp.test lldb-shell :: Subprocess/vfork-follow-child-wp.test lldb-shell :: Subprocess/vfork-follow-parent-wp.test lldb-shell :: Watchpoint/ExpressionLanguage.test Depends on: #118043 Reviewed By: SixWeining Pull Request: https://github.com/llvm/llvm-project/pull/118770 | 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][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 | 3 年前 | |
[lldb][NFC] Fix all formatting errors in .cpp file headers Summary: A *.cpp file header in LLDB (and in LLDB) should like this: //===-- TestUtilities.cpp -------------------------------------------------===// However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator -*- C++ -*- is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing ===// (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258 | 6 年前 | |
Combine multiple defs of arm64 register sets Summary: This patch aims to combine similar arm64 register set definitions defined in NativeRegisterContextLinux_arm64 and RegisterContextPOSIX_arm64. I have implemented a register set interface out of RegisterInfoInterface class and moved arm64 register sets into RegisterInfosPOSIX_arm64 which is similar to Utility/RegisterContextLinux_* implemented by various other targets. This will help in managing register sets of new ARM64 architecture features in one place. Built and tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabihf targets. Reviewers: labath Reviewed By: labath Subscribers: mhorne, emaste, kristof.beyls, atanasyan, danielkiss, lldb-commits Differential Revision: https://reviews.llvm.org/D80105 | 5 年前 | |
Revert "[lldb] Move UnixSignals creation into Platform plugins" This reverts commit ee232506b870ce5282cc4da5ca493d41d361feb3. As discussed in https://reviews.llvm.org/D146668 we'll find another way forward. | 3 年前 | |
[lldb][NFC] Minor formatting nits with some of the NetBSD code | 2 年前 | |
[lldb] Add OpenBSD signals (#123005) Signals 1-32 are matching the default UNIX platform. There are platform specific ones above 32. | 1 年前 | |
[lldb] Add OpenBSD signals (#123005) Signals 1-32 are matching the default UNIX platform. There are platform specific ones above 32. | 1 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb] Remove broken comments originally written as table headers (NFC) (#116089) Automatic formatting has removed the utility of these comments. | 1 年前 | |
[lldb] Refactor DataBuffer so we can map files as read-only Currently, all data buffers are assumed to be writable. This is a problem on macOS where it's not allowed to load unsigned binaries in memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our platform. Binaries are mapped through FileSystem::CreateDataBuffer which returns a DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer because every DataBuffer in LLDB is considered to be writable. In order to use a read-only llvm::MemoryBuffer I had to split our abstraction around it. This patch distinguishes between a DataBuffer (read-only) and WritableDataBuffer (read-write) and updates LLDB to use the appropriate one. rdar://74890607 Differential revision: https://reviews.llvm.org/D122856 | 4 年前 | |
[lldb] Add dummy field to RegisterInfo for register flags use later This structure is supposed to be trivial, so we cannot simply do "= nullptr;" on the new member. Doing that means you are non trivial, regardless of whether you emulate the previously implied constructor somehow. The next option is to update every use of brace initialisation. Given that this is some hundreds of lines, this change just adds a dummy pointer that is set to nullptr. Subsequent changes will actually use that to point to register flags information. Note: This change is not clang-format-ted because it changes a bunch of areas that are not themselves formatted. It would just add noise. Reviewed By: jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D145568 | 3 年前 | |
[lldb] Refactor DataBuffer so we can map files as read-only Currently, all data buffers are assumed to be writable. This is a problem on macOS where it's not allowed to load unsigned binaries in memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our platform. Binaries are mapped through FileSystem::CreateDataBuffer which returns a DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer because every DataBuffer in LLDB is considered to be writable. In order to use a read-only llvm::MemoryBuffer I had to split our abstraction around it. This patch distinguishes between a DataBuffer (read-only) and WritableDataBuffer (read-write) and updates LLDB to use the appropriate one. rdar://74890607 Differential revision: https://reviews.llvm.org/D122856 | 4 年前 | |
[lldb][MachO] MachO corefile support for riscv32 binaries (#137092) Add support for reading a macho corefile with CPU_TYPE_RISCV and the riscv32 general purpose register file. I added code for the floating point and exception registers too, but haven't exercised this. If we start putting the full CSR register bank in a riscv corefile, it'll be in separate 4k byte chunks, but I don't have a corefile to test against that so I haven't written the code to read it. The RegisterContextDarwin_riscv32 is copied & in the style of the other RegisterContextDarwin classes; it's not the first choice I would make for representing this, but it wasn't worth changing for this cputype. rdar://145014653 | 1 年前 | |
[lldb][MachO] MachO corefile support for riscv32 binaries (#137092) Add support for reading a macho corefile with CPU_TYPE_RISCV and the riscv32 general purpose register file. I added code for the floating point and exception registers too, but haven't exercised this. If we start putting the full CSR register bank in a riscv corefile, it'll be in separate 4k byte chunks, but I don't have a corefile to test against that so I haven't written the code to read it. The RegisterContextDarwin_riscv32 is copied & in the style of the other RegisterContextDarwin classes; it's not the first choice I would make for representing this, but it wasn't worth changing for this cputype. rdar://145014653 | 1 年前 | |
[lldb] Remove broken comments originally written as table headers (NFC) (#116089) Automatic formatting has removed the utility of these comments. | 1 年前 | |
[lldb] Refactor DataBuffer so we can map files as read-only Currently, all data buffers are assumed to be writable. This is a problem on macOS where it's not allowed to load unsigned binaries in memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our platform. Binaries are mapped through FileSystem::CreateDataBuffer which returns a DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer because every DataBuffer in LLDB is considered to be writable. In order to use a read-only llvm::MemoryBuffer I had to split our abstraction around it. This patch distinguishes between a DataBuffer (read-only) and WritableDataBuffer (read-write) and updates LLDB to use the appropriate one. rdar://74890607 Differential revision: https://reviews.llvm.org/D122856 | 4 年前 | |
[lldb] Refactor DataBuffer so we can map files as read-only Currently, all data buffers are assumed to be writable. This is a problem on macOS where it's not allowed to load unsigned binaries in memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our platform. Binaries are mapped through FileSystem::CreateDataBuffer which returns a DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer because every DataBuffer in LLDB is considered to be writable. In order to use a read-only llvm::MemoryBuffer I had to split our abstraction around it. This patch distinguishes between a DataBuffer (read-only) and WritableDataBuffer (read-write) and updates LLDB to use the appropriate one. rdar://74890607 Differential revision: https://reviews.llvm.org/D122856 | 4 年前 | |
[lldb] Refactor DataBuffer so we can map files as read-only Currently, all data buffers are assumed to be writable. This is a problem on macOS where it's not allowed to load unsigned binaries in memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our platform. Binaries are mapped through FileSystem::CreateDataBuffer which returns a DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer because every DataBuffer in LLDB is considered to be writable. In order to use a read-only llvm::MemoryBuffer I had to split our abstraction around it. This patch distinguishes between a DataBuffer (read-only) and WritableDataBuffer (read-write) and updates LLDB to use the appropriate one. rdar://74890607 Differential revision: https://reviews.llvm.org/D122856 | 4 年前 | |
[LLDB] Fix: make m_target_arch private Using GetTargetArchitecture() instead of m_target_arch, and set m_target_arch to private. Reviewed By: DavidSpickett Differential Revision: https://reviews.llvm.org/D132353 | 3 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[LLDB] Fix: make m_target_arch private Using GetTargetArchitecture() instead of m_target_arch, and set m_target_arch to private. Reviewed By: DavidSpickett Differential Revision: https://reviews.llvm.org/D132353 | 3 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[LLDB] Fix: make m_target_arch private Using GetTargetArchitecture() instead of m_target_arch, and set m_target_arch to private. Reviewed By: DavidSpickett Differential Revision: https://reviews.llvm.org/D132353 | 3 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[LLDB, FreeBSD, x86] Fix empty register set when trying to get size of register (#162890) The register set information is stored as a singleton in GetRegisterInfo_i386. However, other functions later access this information assuming it is stored in GetSharedRegisterInfoVector. To resolve this inconsistency, we remove the original construction logic and instead initialize the singleton using llvm::call_once within the appropriate function (GetSharedRegisterInfoVector_i386). | 9 个月前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb] Refactor DataBuffer so we can map files as read-only Currently, all data buffers are assumed to be writable. This is a problem on macOS where it's not allowed to load unsigned binaries in memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our platform. Binaries are mapped through FileSystem::CreateDataBuffer which returns a DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer because every DataBuffer in LLDB is considered to be writable. In order to use a read-only llvm::MemoryBuffer I had to split our abstraction around it. This patch distinguishes between a DataBuffer (read-only) and WritableDataBuffer (read-write) and updates LLDB to use the appropriate one. rdar://74890607 Differential revision: https://reviews.llvm.org/D122856 | 4 年前 | |
[lldb] Refactor DataBuffer so we can map files as read-only Currently, all data buffers are assumed to be writable. This is a problem on macOS where it's not allowed to load unsigned binaries in memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our platform. Binaries are mapped through FileSystem::CreateDataBuffer which returns a DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer because every DataBuffer in LLDB is considered to be writable. In order to use a read-only llvm::MemoryBuffer I had to split our abstraction around it. This patch distinguishes between a DataBuffer (read-only) and WritableDataBuffer (read-write) and updates LLDB to use the appropriate one. rdar://74890607 Differential revision: https://reviews.llvm.org/D122856 | 4 年前 | |
[lldb] Add dummy field to RegisterInfo for register flags use later This structure is supposed to be trivial, so we cannot simply do "= nullptr;" on the new member. Doing that means you are non trivial, regardless of whether you emulate the previously implied constructor somehow. The next option is to update every use of brace initialisation. Given that this is some hundreds of lines, this change just adds a dummy pointer that is set to nullptr. Subsequent changes will actually use that to point to register flags information. Note: This change is not clang-format-ted because it changes a bunch of areas that are not themselves formatted. It would just add noise. Reviewed By: jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D145568 | 3 年前 | |
[lldb] Drop RegisterInfoInterface::GetDynamicRegisterInfo "Dynamic register info" is a very overloaded term, and this particular instance of it was only used for passing the information about the "orig_[re]ax" pseudo-register on x86 through some generic code. Since both sides of the code are x86-specific, I have replaced this with a more direct route. Differential Revision: https://reviews.llvm.org/D147045 | 3 年前 | |
[lldb] Drop RegisterInfoInterface::GetDynamicRegisterInfo "Dynamic register info" is a very overloaded term, and this particular instance of it was only used for passing the information about the "orig_[re]ax" pseudo-register on x86 through some generic code. Since both sides of the code are x86-specific, I have replaced this with a more direct route. Differential Revision: https://reviews.llvm.org/D147045 | 3 年前 | |
[lldb] Drop RegisterInfoInterface::GetDynamicRegisterInfo "Dynamic register info" is a very overloaded term, and this particular instance of it was only used for passing the information about the "orig_[re]ax" pseudo-register on x86 through some generic code. Since both sides of the code are x86-specific, I have replaced this with a more direct route. Differential Revision: https://reviews.llvm.org/D147045 | 3 年前 | |
[lldb] Remove unused functions from RegisterContextLinux_x86 These should be overridden by individual subclasses, they ended up here because of copy-pasta. | 3 年前 | |
[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 | 3 年前 | |
[lldb] Remove unused private field 'm_orig_rax_info' in RegisterContextLinux_x86_64.h (NFC) /data/llvm-project/lldb/source/Plugins/Process/Utility/RegisterContextLinux_x86_64.h:32:30: error: private field 'm_orig_rax_info' is not used [-Werror,-Wunused-private-field] lldb_private::RegisterInfo m_orig_rax_info; ^ 1 error generated. | 3 年前 | |
[lldb] Replace default bodies of special member functions with = default; Replace default bodies of special member functions with = default; $ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix , https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html Differential revision: https://reviews.llvm.org/D104041 | 5 年前 | |
[lldb] Fix modernize-use-override warnings (NFC) Fix modernize-use-override warnings. Because this check is listed in LLDB's top level .clang-tidy configuration, the check is enabled by default and the resulting warnings show up in my editor. I've audited the modified lines. This is not a blind change. | 4 年前 | |
[lldb] Replace default bodies of special member functions with = default; Replace default bodies of special member functions with = default; $ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix , https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html Differential revision: https://reviews.llvm.org/D104041 | 5 年前 | |
[lldb] Fix modernize-use-override warnings (NFC) Fix modernize-use-override warnings. Because this check is listed in LLDB's top level .clang-tidy configuration, the check is enabled by default and the resulting warnings show up in my editor. I've audited the modified lines. This is not a blind change. | 4 年前 | |
[LLDB] Pass const RegisterInfo& to RegisterValue::SetValueFromData Familiar story, callers are either checking upfront that the pointer wasn't null or not checking at all. SetValueFromData itself didn't check either. So make the parameter a ref and fixup the few places where a nullptr check seems needed. Depends on D135668 Reviewed By: clayborg Differential Revision: https://reviews.llvm.org/D135670 | 3 年前 | |
[lldb] Refactor DataBuffer so we can map files as read-only Currently, all data buffers are assumed to be writable. This is a problem on macOS where it's not allowed to load unsigned binaries in memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our platform. Binaries are mapped through FileSystem::CreateDataBuffer which returns a DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer because every DataBuffer in LLDB is considered to be writable. In order to use a read-only llvm::MemoryBuffer I had to split our abstraction around it. This patch distinguishes between a DataBuffer (read-only) and WritableDataBuffer (read-write) and updates LLDB to use the appropriate one. rdar://74890607 Differential revision: https://reviews.llvm.org/D122856 | 4 年前 | |
[lldb][NFC] Minor formatting nits with some of the NetBSD code | 2 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[NFC][TargetParser] Remove llvm/ADT/Triple.h I also ran git clang-format to get the headers in the right order for the new location, which has changed the order of other headers in two files. | 3 年前 | |
[lldb][NFC] Minor formatting nits with some of the NetBSD code | 2 年前 | |
[LLDB] Fix: make m_target_arch private Using GetTargetArchitecture() instead of m_target_arch, and set m_target_arch to private. Reviewed By: DavidSpickett Differential Revision: https://reviews.llvm.org/D132353 | 3 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb][NFC] Fix all formatting errors in .cpp file headers Summary: A *.cpp file header in LLDB (and in LLDB) should like this: //===-- TestUtilities.cpp -------------------------------------------------===// However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator -*- C++ -*- is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing ===// (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258 | 6 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb] Replace default bodies of special member functions with = default; Replace default bodies of special member functions with = default; $ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix , https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html Differential revision: https://reviews.llvm.org/D104041 | 5 年前 | |
[lldb] Remove bogus ProcessMonitor forward-decls This class is not used in those files. | 5 年前 | |
[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] 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][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][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] Silence warning with Clang ToT This fixes -Wcovered-switch-default warnings. This is a reminiscent of an old refactoring, see ce03a862372a6f36d2fcf80dc80052aa155fcae8. | 2 年前 | |
[lldb] Remove bogus ProcessMonitor forward-decls This class is not used in those files. | 5 年前 | |
[lldb] Replace default bodies of special member functions with = default; Replace default bodies of special member functions with = default; $ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix , https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html Differential revision: https://reviews.llvm.org/D104041 | 5 年前 | |
[lldb] Remove bogus ProcessMonitor forward-decls This class is not used in those files. | 5 年前 | |
[lldb][NFC] Use C++ versions of the deprecated C standard library headers The C headers are deprecated so as requested in D102845, this is replacing them all with their (not deprecated) C++ equivalent. Reviewed By: shafik Differential Revision: https://reviews.llvm.org/D103084 | 5 年前 | |
Remove code duplication from RegisterContextPOSIX_* Summary: This patch aims to remove multiple copies of GetByteOrder() and ConvertRegisterKindToRegisterNumber used in various versions of RegisterContextPOSIX_*. Both register implementations are move to RegisterContext class which is parent of RegisterContextPOSIX_* classes. Built and tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabihf targets. Reviewers: labath Reviewed By: labath Subscribers: wuzish, nemanjai, kristof.beyls, kbarton, atanasyan, lldb-commits Differential Revision: https://reviews.llvm.org/D80104 | 6 年前 | |
[lldb] Support riscv32 ELF corefiles (#115408) Add support for riscv32 ELF corefiles. | 1 年前 | |
[lldb] Support riscv32 ELF corefiles (#115408) Add support for riscv32 ELF corefiles. | 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][RISCV] Add riscv register definition and read/write This patch is based on the minimal extract of D128250. What is implemented: - Use the same register layout as Linux kernel and mock read/write for x0 register (the always zero register). - Refactor some duplicate code, and delete unused register definitions. Reviewed By: DavidSpickett Differential Revision: https://reviews.llvm.org/D130342 | 3 年前 | |
[LLDB] Fix: make m_target_arch private Using GetTargetArchitecture() instead of m_target_arch, and set m_target_arch to private. Reviewed By: DavidSpickett Differential Revision: https://reviews.llvm.org/D132353 | 3 年前 | |
[lldb] Remove bogus ProcessMonitor forward-decls This class is not used in those files. | 5 年前 | |
[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 | 3 年前 | |
[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 | 3 年前 | |
[lldb] Fix incorrect conversion from boolean in RegisterContextThreadMemory (#151767) The method ConvertRegisterKindToRegisterNumber should return INVALID_REGNUM, and not "false" upon failure: false would mean 0 which is usually the number for generic PC. Likewise, NumSupportedHardwareBreakpoints should return 0 instead of false (though for this one they are equivalent). | 1 年前 | |
[lldb] Make RegisterContextThreadMemory thread safe (#134469) The UpdateRegisterContext method can be called from multiple threads. | 1 年前 | |
[lldb] Add dummy field to RegisterInfo for register flags use later This structure is supposed to be trivial, so we cannot simply do "= nullptr;" on the new member. Doing that means you are non trivial, regardless of whether you emulate the previously implied constructor somehow. The next option is to update every use of brace initialisation. Given that this is some hundreds of lines, this change just adds a dummy pointer that is set to nullptr. Subsequent changes will actually use that to point to register flags information. Note: This change is not clang-format-ted because it changes a bunch of areas that are not themselves formatted. It would just add noise. Reviewed By: jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D145568 | 3 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb] Add dummy field to RegisterInfo for register flags use later This structure is supposed to be trivial, so we cannot simply do "= nullptr;" on the new member. Doing that means you are non trivial, regardless of whether you emulate the previously implied constructor somehow. The next option is to update every use of brace initialisation. Given that this is some hundreds of lines, this change just adds a dummy pointer that is set to nullptr. Subsequent changes will actually use that to point to register flags information. Note: This change is not clang-format-ted because it changes a bunch of areas that are not themselves formatted. It would just add noise. Reviewed By: jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D145568 | 3 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb] Reland "Use translated full ftag values" Translate between abridged and full ftag values in order to expose the latter in the gdb-remote protocol while the former are used by FXSAVE/XSAVE... This matches the gdb behavior. The Shell/Register tests now rely on the new behavior, and therefore are run on non-Darwin systems only. The Python (API) test relies on the legacy behavior, and is run on Darwin only. Differential Revision: https://reviews.llvm.org/D91504 | 5 年前 | |
[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 | 3 年前 | |
[lldb][AArch64][Linux] Show MTE store only setting in mte_ctrl (#145033) This controls whether tag checking is performed for loads and stores, or stores only. It requires a specific architecture feature which we detect with a HWCAP3 and cpuinfo feature. Live process tests look for this and adjust expectations accordingly, core file tests are using an updated file with this feature enabled. The size of the core file has increased and there's nothing I can do about that. Could be the presence of new architecure features or kernel changes since I last generated them. I can generate a smaller file that has the tag segment, but that segment does not actually contain tag data. So that's no use. | 1 年前 | |
[lldb][AArch64] Add HWCAP3 to register field detection (#145029) This will be used to detect the presence of Arm's new Memory Tagging store only checking feature. This commit just adds the plumbing to get that value into the detection function. FreeBSD has not allocated a number for HWCAP3 and already has AT_ARGV defined as 29. So instead of attempting to read from FreeBSD processes, I've explicitly passed 0. We don't want to be reading some other entry accidentally. If/when FreeBSD adds HWCAP3 we can handle it like we do for AUXV_FREEBSD_AT_HWCAP. No extra tests here, those will be coming with the next change for MTE support. | 1 年前 | |
Combine multiple defs of arm64 register sets Summary: This patch aims to combine similar arm64 register set definitions defined in NativeRegisterContextLinux_arm64 and RegisterContextPOSIX_arm64. I have implemented a register set interface out of RegisterInfoInterface class and moved arm64 register sets into RegisterInfosPOSIX_arm64 which is similar to Utility/RegisterContextLinux_* implemented by various other targets. This will help in managing register sets of new ARM64 architecture features in one place. Built and tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabihf targets. Reviewers: labath Reviewed By: labath Subscribers: mhorne, emaste, kristof.beyls, atanasyan, danielkiss, lldb-commits Differential Revision: https://reviews.llvm.org/D80105 | 5 年前 | |
[lldb] Drop RegisterInfoInterface::GetDynamicRegisterInfo "Dynamic register info" is a very overloaded term, and this particular instance of it was only used for passing the information about the "orig_[re]ax" pseudo-register on x86 through some generic code. Since both sides of the code are x86-specific, I have replaced this with a more direct route. Differential Revision: https://reviews.llvm.org/D147045 | 3 年前 | |
[lldb] Add dummy field to RegisterInfo for register flags use later This structure is supposed to be trivial, so we cannot simply do "= nullptr;" on the new member. Doing that means you are non trivial, regardless of whether you emulate the previously implied constructor somehow. The next option is to update every use of brace initialisation. Given that this is some hundreds of lines, this change just adds a dummy pointer that is set to nullptr. Subsequent changes will actually use that to point to register flags information. Note: This change is not clang-format-ted because it changes a bunch of areas that are not themselves formatted. It would just add noise. Reviewed By: jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D145568 | 3 年前 | |
Move NativeRegisterContextLinux/RegisterContextPOSIX*_arm to RegisterInfoAndSetInterface This patch removes register set definitions and other redundant code from NativeRegisterContextLinux/RegisterContextPOSIX*_arm. Register sets are now moved under RegisterInfosPOSIX_arm which now uses RegisterInfoAndSetInterface. This is similar to what we earlier did for AArch64. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D86962 | 5 年前 | |
[LLDB][AArch64] Make TPIDR a generic tp register (#154444) Unlike x86, ARM doesn't support a generic thread pointer for TLS data, so things like reg read tp ... memory read tp Don't work, and you need to specify tpidr. This works, especially because that's the name GDB uses. But for ease of use, and at the request of @aperez I've made it so we can reference it via tp. I personally don't have an aarch machine, and all the arm examples in Shell/Register/Core are freebsd and don't contain tpidr, so I was unable to add a shell test for this. I added a test to the AARCH register tests, but without an Aarch machine I'm hoping these work. | 10 个月前 | |
[lldb] Fix UBSan complaints for #151460 | 11 个月前 | |
[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][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][NFC] Use C++ versions of the deprecated C standard library headers The C headers are deprecated so as requested in D102845, this is replacing them all with their (not deprecated) C++ equivalent. Reviewed By: shafik Differential Revision: https://reviews.llvm.org/D103084 | 5 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb] Support riscv32 ELF corefiles (#115408) Add support for riscv32 ELF corefiles. | 1 年前 | |
[lldb] Support riscv32 ELF corefiles (#115408) Add support for riscv32 ELF corefiles. | 1 年前 | |
[lldb] Support riscv32 ELF corefiles (#115408) Add support for riscv32 ELF corefiles. | 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] Remove broken comments originally written as table headers (NFC) (#116089) Automatic formatting has removed the utility of these comments. | 1 年前 | |
[LLDB][AArch64] Make TPIDR a generic tp register (#154444) Unlike x86, ARM doesn't support a generic thread pointer for TLS data, so things like reg read tp ... memory read tp Don't work, and you need to specify tpidr. This works, especially because that's the name GDB uses. But for ease of use, and at the request of @aperez I've made it so we can reference it via tp. I personally don't have an aarch machine, and all the arm examples in Shell/Register/Core are freebsd and don't contain tpidr, so I was unable to add a shell test for this. I added a test to the AARCH register tests, but without an Aarch machine I'm hoping these work. | 10 个月前 | |
[lldb] Add dummy field to RegisterInfo for register flags use later This structure is supposed to be trivial, so we cannot simply do "= nullptr;" on the new member. Doing that means you are non trivial, regardless of whether you emulate the previously implied constructor somehow. The next option is to update every use of brace initialisation. Given that this is some hundreds of lines, this change just adds a dummy pointer that is set to nullptr. Subsequent changes will actually use that to point to register flags information. Note: This change is not clang-format-ted because it changes a bunch of areas that are not themselves formatted. It would just add noise. Reviewed By: jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D145568 | 3 年前 | |
[lldb] Add dummy field to RegisterInfo for register flags use later This structure is supposed to be trivial, so we cannot simply do "= nullptr;" on the new member. Doing that means you are non trivial, regardless of whether you emulate the previously implied constructor somehow. The next option is to update every use of brace initialisation. Given that this is some hundreds of lines, this change just adds a dummy pointer that is set to nullptr. Subsequent changes will actually use that to point to register flags information. Note: This change is not clang-format-ted because it changes a bunch of areas that are not themselves formatted. It would just add noise. Reviewed By: jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D145568 | 3 年前 | |
[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][NFC] Use C++ versions of the deprecated C standard library headers The C headers are deprecated so as requested in D102845, this is replacing them all with their (not deprecated) C++ equivalent. Reviewed By: shafik Differential Revision: https://reviews.llvm.org/D103084 | 5 年前 | |
[lldb] Add dummy field to RegisterInfo for register flags use later This structure is supposed to be trivial, so we cannot simply do "= nullptr;" on the new member. Doing that means you are non trivial, regardless of whether you emulate the previously implied constructor somehow. The next option is to update every use of brace initialisation. Given that this is some hundreds of lines, this change just adds a dummy pointer that is set to nullptr. Subsequent changes will actually use that to point to register flags information. Note: This change is not clang-format-ted because it changes a bunch of areas that are not themselves formatted. It would just add noise. Reviewed By: jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D145568 | 3 年前 | |
[lldb] Add dummy field to RegisterInfo for register flags use later This structure is supposed to be trivial, so we cannot simply do "= nullptr;" on the new member. Doing that means you are non trivial, regardless of whether you emulate the previously implied constructor somehow. The next option is to update every use of brace initialisation. Given that this is some hundreds of lines, this change just adds a dummy pointer that is set to nullptr. Subsequent changes will actually use that to point to register flags information. Note: This change is not clang-format-ted because it changes a bunch of areas that are not themselves formatted. It would just add noise. Reviewed By: jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D145568 | 3 年前 | |
[lldb] Add dummy field to RegisterInfo for register flags use later This structure is supposed to be trivial, so we cannot simply do "= nullptr;" on the new member. Doing that means you are non trivial, regardless of whether you emulate the previously implied constructor somehow. The next option is to update every use of brace initialisation. Given that this is some hundreds of lines, this change just adds a dummy pointer that is set to nullptr. Subsequent changes will actually use that to point to register flags information. Note: This change is not clang-format-ted because it changes a bunch of areas that are not themselves formatted. It would just add noise. Reviewed By: jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D145568 | 3 年前 | |
[lldb] Add dummy field to RegisterInfo for register flags use later This structure is supposed to be trivial, so we cannot simply do "= nullptr;" on the new member. Doing that means you are non trivial, regardless of whether you emulate the previously implied constructor somehow. The next option is to update every use of brace initialisation. Given that this is some hundreds of lines, this change just adds a dummy pointer that is set to nullptr. Subsequent changes will actually use that to point to register flags information. Note: This change is not clang-format-ted because it changes a bunch of areas that are not themselves formatted. It would just add noise. Reviewed By: jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D145568 | 3 年前 | |
[lldb] Support riscv32 ELF corefiles (#115408) Add support for riscv32 ELF corefiles. | 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] Add dummy field to RegisterInfo for register flags use later This structure is supposed to be trivial, so we cannot simply do "= nullptr;" on the new member. Doing that means you are non trivial, regardless of whether you emulate the previously implied constructor somehow. The next option is to update every use of brace initialisation. Given that this is some hundreds of lines, this change just adds a dummy pointer that is set to nullptr. Subsequent changes will actually use that to point to register flags information. Note: This change is not clang-format-ted because it changes a bunch of areas that are not themselves formatted. It would just add noise. Reviewed By: jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D145568 | 3 年前 | |
[lldb] Add dummy field to RegisterInfo for register flags use later This structure is supposed to be trivial, so we cannot simply do "= nullptr;" on the new member. Doing that means you are non trivial, regardless of whether you emulate the previously implied constructor somehow. The next option is to update every use of brace initialisation. Given that this is some hundreds of lines, this change just adds a dummy pointer that is set to nullptr. Subsequent changes will actually use that to point to register flags information. Note: This change is not clang-format-ted because it changes a bunch of areas that are not themselves formatted. It would just add noise. Reviewed By: jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D145568 | 3 年前 | |
[lldb] Implement thread local storage for linux (#67470) This patch implements the thread local storage support for linux (https://github.com/llvm/llvm-project/issues/28766). TLS feature is originally only implemented for Mac. With my previous patch to enable fs_base register for Linux (https://reviews.llvm.org/D155256), now it is feasible to implement this feature for Linux. The major changes are: * Track the main module's link address during launch * Fetch thread pointer from fs_base register * Create register alias for thread pointer * Read pthread metadata from target memory instead of process so that it works for coredump With the patch the failing test is passing now. Note: I am only enabling this test for Mac and Linux because I do not have machine to test for FreeBSD/NetBSD. --------- Co-authored-by: jeffreytan81 <jeffreytan@fb.com> | 2 年前 | |
[lldb] Fix -Wreturn-type in RegisterInfos_x86_64_with_base_shared.cpp (NFC) /data/llvm-project/lldb/source/Plugins/Process/Utility/RegisterInfos_x86_64_with_base_shared.cpp:319:1: error: non-void function does not return a value in all control paths [-Werror,-Wreturn-type] } ^ 1 error generated. | 3 年前 | |
[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 | 3 年前 | |
[lldb] Correct 32-bit build failure in StopInfoMachException.cpp (#159523) uintptr_t is usually a good idea when handling pointers, but lldb has to handle 64-bit addresses that might be from a remote system, on a 32-bit system. So I've changed a few instances here to use addr_t which is 64-bit everywhere. Before we got: https://lab.llvm.org/buildbot/#/builders/18/builds/21247 ../llvm-project/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp:81:28: error: constexpr variable 'g_mte_tag_mask' must be initialized by a constant expression 81 | static constexpr uintptr_t g_mte_tag_mask = (uintptr_t)0x0f << g_mte_tag_shift; | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../llvm-project/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp:81:61: note: shift count 56 >= width of type 'uintptr_t' (aka 'unsigned int') (32 bits) 81 | static constexpr uintptr_t g_mte_tag_mask = (uintptr_t)0x0f << g_mte_tag_shift; | ^ 1 error generated. Original code added by #159117. | 10 个月前 | |
[lldb] Recognize MTE fault Mach exceptions (#159117) Recognize an MTE tag fault Mach exception. A tag fault is an error reported by Arm's Memory Tagging Extension (MTE) when a memory access attempts to use a pointer with a tag that doesn't match the tag stored with the memory. LLDB will print the tag and address to make the issue easier to diagnose. This was hand tested by debugging an MTE enabled binary on an iPhone 17 running iOS 26. rdar://113575216 | 10 个月前 | |
[lldb][NFC] Break ThreadMemory into smaller abstractions (#132905) ThreadMemory attempts to be a class abstracting the notion of a "fake" Thread that is backed by a "real" thread. According to its documentation, it is meant to be a class forwarding most methods to the backing thread, but it does so only for a handful of methods. Along the way, it also tries to represent a Thread that may or may not have a different name, and may or may not have a different queue from the backing thread. This can be problematic for a couple of reasons: 1. It forces all users into this optional behavior. 2. The forwarding behavior is incomplete: not all methods are currently being forwarded properly. Some of them involve queues and seem to have been intentionally left unimplemented. This commit creates the following separation: ThreadMemory <- ThreadMemoryProvidingName <- ThreadMemoryProvidingNameAndQueue ThreadMemory captures the notion of a backed thread that _really_ forwards all methods to the backing thread. (Missing methods should be implemented in a later commit, and allowing them to be implemented without changing behavior of other derived classes is the main purpose of this refactor). ThreadMemoryProvidingNameAndQueue is a ThreadMemory that allows users to override the thread name. If a name is present, it is used; otherwise the forwarding behavior is used. ThreadMemoryProvidingNameAndQueue is a ThreadMemoryProvidingName that allows users to override queue information. If queue information is present, it is used; otherwise, the forwarding behavior is used. With this separation, we can more explicitly implement missing methods of the base class and override them, if needed, in ThreadMemoryProvidingNameAndQueue. But this commit really is NFC, no new methods are implemented and no method implementation is changed. | 1 年前 | |
[lldb] Implement missing queue overloads from ThreadMemory (#132906) This commit makes ThreadMemory a real "forwarder" class by implementing the missing queue methods: they will just call the corresponding backing thread method. To make this patch NFC(*) and not change the behavior of the Python OS plugin, NamedThreadMemoryWithQueue also overrides these methods to simply call the Thread method, just as it was doing before. This also makes it obvious that there are missing pieces of this class if it were to provide full queue support. (*) This patch is NFC in the sense that all llvm.org plugins will not have any behavior change, but downstream consumers of ThreadMemory will benefit from the newly implemented forwarding methods. | 1 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[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] [Process/FreeBSD] Introduce mips64 FPU reg support Differential Revision: https://reviews.llvm.org/D96766 | 4 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[LLDB][RISCV] Add RVV registers enums RVV stands for "RISC-V V Extension", which adds 32 vector registers, and seven unprivileged CSRs (vstart, vxsat, vxrm, vcsr, vtype, vl, vlenb) to a base scalar RISC-V ISA. The base vector extension is intended to provide general support for data-parallel execution within the 32-bit instruction encoding space, with later vector extensions supporting richer functionality for certain domains. Reviewed By: DavidSpickett, kito-cheng Differential Revision: https://reviews.llvm.org/D141898 | 3 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[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 | 3 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 6 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 11 个月前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 9 个月前 | ||
| 3 年前 | ||
| 11 个月前 | ||
| 11 个月前 | ||
| 10 个月前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 5 年前 | ||
| 9 个月前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 11 个月前 | ||
| 11 个月前 | ||
| 11 个月前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 6 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 6 年前 | ||
| 1 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 6 年前 | ||
| 3 年前 | ||
| 6 年前 | ||
| 3 年前 | ||
| 6 年前 | ||
| 9 个月前 | ||
| 6 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 6 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 6 年前 | ||
| 3 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 10 个月前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 5 年前 | ||
| 6 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 10 个月前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 1 年前 | ||
| 4 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 3 年前 | ||
| 6 年前 | ||
| 3 年前 |