| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[feature] simd上支持断点类型识别问题 Co-authored-by: wangyixian<wangyixian3@huawei.com> # message auto-generated for no-merge-commit merge: !165 merge fix_bt into master [feature] simd上支持断点类型识别问题 Created-by: wiyr0 Commit-by: wiyr0;wangyixian Merged-by: ascend-robot Description: ### 1. 修改描述 - **修改原因：** simd_vf上的函数都是inlined行为，不能直接通过函数类型去识别 - **修改方案：** 通过pc对应的block块，为每个block设置函数类型，若当前block没有函数类型信息，则通过父节点寻找 - **修改内容：** 为lldb/include/lldb/Symbol/Block.h里的Block类增加m_function_class字段；SymbolFileDWARF::ParseBlocksRecursive函数里为Block 设置函数类型。 - [ ] **涉及代码双合**(贴上另一个PR链接)：NA ---- ### 2. 功能验证 - [ ] **功能自验截图**（请确保不体现个人信息） - [x] **冒烟是否通过**  ---- ### 3. 代码检视 - **要求：** - 合入功能代码大于 200 行，需要sig会议申报代码检视议题，并在PR中标注会议。 - committer评估是否需要在sig会议进行代码检视。 - 参与检视的committer人员名单与检视时间。 - 大于 1000 行代码原则上不允许合入，需进行备案。 - [x] **是否经过代码检视** - [ ] **是否具备UT测试用例看护** NA - [ ] **是否需要在sig会议中进行代码检视** - **检视committer人员名单与检视时间：** NA ---- ### 4. 资料修改自检 - **资料修改：** NA ---- See merge request: Ascend/msdebug!165 | 1 个月前 | |
Move from llvm::makeArrayRef to ArrayRef deduction guides - last part This is a follow-up to https://reviews.llvm.org/D140896, split into several parts as it touches a lot of files. Differential Revision: https://reviews.llvm.org/D141298 | 3 年前 | |
[lldb] Use const reference for range variables to improve performance (NFC) (#94840) Cppcheck recommends using a const reference for range variables in a for-each loop. This avoids unnecessary copying of elements, improving performance. Caught by cppcheck - lldb/source/API/SBBreakpoint.cpp:717:22: performance: Range variable 'name' should be declared as const reference. [iterateByValue] lldb/source/API/SBTarget.cpp:1150:15: performance: Range variable 'name' should be declared as const reference. [iterateByValue] lldb/source/Breakpoint/Breakpoint.cpp:888:26: performance: Range variable 'name' should be declared as const reference. [iterateByValue] lldb/source/Breakpoint/BreakpointIDList.cpp:262:26: performance: Range variable 'name' should be declared as const reference. [iterateByValue] Fix #91213 Fix #91217 Fix #91219 Fix #91220 | 2 年前 | |
[lldb][NFCI] Remove EventData* param from BroadcastEvent (#78773) BroadcastEvent currently takes its EventData* param and shoves it into an Event object, which takes ownership of the pointer and places it into a shared_ptr to manage the lifetime. Instead of relying on new and passing raw pointers around, I think it would make more sense to create the shared_ptr up front. | 2 年前 | |
[lldb] Display breakpoint locations using display name (#90297) Adds a show_function_display_name parameter to SymbolContext::DumpStopContext. This parameter defaults to false, but BreakpointLocation::GetDescription sets it to true. This is NFC in mainline lldb, and will be used to modify how Swift breakpoint locations are printed. | 2 年前 | |
Add a repeat command option for "thread backtrace --count N". This way if you have a long stack, you can issue "thread backtrace --count 10" and then subsequent <Return>-s will page you through the stack. This took a little more effort than just adding the repeat command, since the GetRepeatCommand API was returning a "const char *". That meant the command had to keep the repeat string alive, which is inconvenient. The original API returned either a nullptr, or a const char *, so I changed the private API to return an llvm::Optional<std::string>. Most of the patch is propagating that change. Also, there was a little thinko in fetching the repeat command. We don't fetch repeat commands for commands that aren't being added to history, which is in general reasonable. And we don't add repeat commands to the history - also reasonable. But we do want the repeat command to be able to generate the NEXT repeat command. So I adjusted the logic in HandleCommand to work that way. Differential Revision: https://reviews.llvm.org/D119046 | 4 年前 | |
[bugfix] 修复host断点与device断点重复时,host断点取消失败导致算子断不到device侧的问题 Co-authored-by: wiyr0<wangyixian3@huawei.com> # message auto-generated for no-merge-commit merge: !181 merge test_host_bkpt into master [bugfix] 修复host断点与device断点重复时,host断点取消失败导致算子断不到device侧的问题 Created-by: wiyr0 Commit-by: wiyr0 Merged-by: ascend-robot Description: ### 1. 修改描述 - **修改原因：** https://gitcode.com/Ascend/msdebug/issues/99 断点设置同时匹配host和device侧时，比如动态库和kernel侧都匹配到了。原本逻辑会去除host侧的断点，但是host侧其实运行后几乎没停下来，取消host断点就会失败，但是实际的算子跑的host断点还在，调试器管理的断点信息不在了。这就会导致host断点命中时，被误认为SIGTRAP类型的中断 - **修改方案：** 当算子运行后，不再对host断点做取消的操作，保持两个host侧和device侧的断点都在 - **修改内容：** BreakpointLocationSP BreakpointLocationList::AddLocation函数里，对host断点删除操作前，先判断process_sp是否为空，为空说明进程还没启动，可以做取消。 - [ ] **涉及代码双合**(贴上另一个PR链接)： ---- ### 2. 功能验证 - [ ] **功能自验截图**（请确保不体现个人信息）   - [x] **冒烟是否通过**  ---- ### 3. 代码检视 - **要求：** - 合入功能代码大于 200 行，需要sig会议申报代码检视议题，并在PR中标注会议。 - committer评估是否需要在sig会议进行代码检视。 - 参与检视的committer人员名单与检视时间。 - 大于 1000 行代码原则上不允许合入，需进行备案。 - [x] **是否经过代码检视** - [ ] **是否具备UT测试用例看护** - [ ] **是否需要在sig会议中进行代码检视** - **检视committer人员名单与检视时间：** ---- ### 4. 资料修改自检 - **资料修改：** ---- See merge request: Ascend/msdebug!181 | 1 个月前 | |
[lldb][NFCI] Remove unused constructors from BreakpointName There is only one constructor in use so the rest can be removed. | 2 年前 | |
Add a unit test for SBBreakpoint::SetCallback (#96001) This commit adds a unit test for SBBreakpoint::SetCallback as it wasn't being tested before. | 2 年前 | |
[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] Make semantics of SupportFile equivalence explicit (#97126) This is an improved attempt to improve the semantics of SupportFile equivalence, taking into account the feedback from #95606. Pavel's comment about the lack of a concise name because the concept isn't trivial made me realize that I don't want to abstract this concept away behind a helper function. Instead, I opted for a rather verbose enum that forces the caller to consider exactly what kind of comparison is appropriate for every call. | 2 年前 | |
[lldb] Fix breakpoint resolver serialization bug (#76766) BreakpointResolverAddress optionally can include the module name related to the address that gets resolved. Currently this will never work because it sets the name to itself (which is empty). | 2 年前 | |
[lldb][Windows] Fixed the TestBreakpointCommand test (#93122) The TestBreakpointCommand test is incorrectly disabled for Windows target. We can disable it for Windows host instead or just fix the issue. This patch fixes the path separator in BreakpointResolverFileLine::DeduceSourceMapping() and the Windows specific absolute path in the test in case of the Windows host. | 2 年前 | |
[lldb][NFCI] Remove unused parameter from BreakpointResolver*::CreateFromStructuredData (#75374) These appear to be unused. | 2 年前 | |
| 2 年前 | ||
[lldb][NFCI] Remove unused parameter from BreakpointResolver*::CreateFromStructuredData (#75374) These appear to be unused. | 2 年前 | |
[lldb] [mostly NFC] Large WP foundation: WatchpointResources (#68845) This patch is rearranging code a bit to add WatchpointResources to Process. A WatchpointResource is meant to represent a hardware watchpoint register in the inferior process. It has an address, a size, a type, and a list of Watchpoints that are using this WatchpointResource. This current patch doesn't add any of the features of WatchpointResources that make them interesting -- a user asking to watch a 24 byte object could watch this with three 8 byte WatchpointResources. Or a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte at 0x1003, these must both be served by a single WatchpointResource on that doubleword at 0x1000 on a 64-bit target, if two hardware watchpoint registers were used to track these separately, one of them may not be hit. Or if you have one Watchpoint on a variable with a condition set, and another Watchpoint on that same variable with a command defined or different condition, or ignorecount, both of those Watchpoints need to evaluate their criteria/commands when their WatchpointResource has been hit. There's a bit of code movement to rearrange things in the direction I'll need for implementing this feature, so I want to start with reviewing & landing this mostly NFC patch and we can focus on the algorithmic choices about how WatchpointResources are shared and handled as they're triggeed, separately. This patch also stops printing "Watchpoint <n> hit: old value: <x>, new vlaue: <y>" for Read watchpoints. I could make an argument for print "Watchpoint <n> hit: current value <x>" but the current output doesn't make any sense, and the user can print the value if they are particularly interested. Read watchpoints are used primarily to understand what code is reading a variable. This patch adds more fallbacks for how to print the objects being watched if we have types, instead of assuming they are all integral values, so a struct will print its elements. As large watchpoints are added, we'll be doing a lot more of those. To track the WatchpointSP in the WatchpointResources, I changed the internal API which took a WatchpointSP and devolved it to a Watchpoint*, which meant touching several different Process files. I removed the watchpoint code in ProcessKDP which only reported that watchpoints aren't supported, the base class does that already. I haven't yet changed how we receive a watchpoint to identify the WatchpointResource responsible for the trigger, and identify all Watchpoints that are using this Resource to evaluate their conditions etc. This is the same work that a BreakpointSite needs to do when it has been tiggered, where multiple Breakpoints may be at the same address. There is not yet any printing of the Resources that a Watchpoint is implemented in terms of ("watchpoint list", or SBWatchpoint::GetDescription). "watchpoint set var" and "watchpoint set expression" take a size argument which was previously 1, 2, 4, or 8 (an enum). I've changed this to an unsigned int. Most hardware implementations can only watch 1, 2, 4, 8 byte ranges, but with Resources we'll allow a user to ask for different sized watchpoints and set them in hardware-expressble terms soon. I've annotated areas where I know there is work still needed with LWP_TODO that I'll be working on once this is landed. I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS. https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116 (cherry picked from commit fc6b72523f3d73b921690a713e97a433c96066c6) | 2 年前 | |
[lldb] Add support for large watchpoints in lldb (#79962) This patch is the next piece of work in my Large Watchpoint proposal, https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116 This patch breaks a user's watchpoint into one or more WatchpointResources which reflect what the hardware registers can cover. This means we can watch objects larger than 8 bytes, and we can watched unaligned address ranges. On a typical 64-bit target with 4 watchpoint registers you can watch 32 bytes of memory if the start address is doubleword aligned. Additionally, if the remote stub implements AArch64 MASK style watchpoints (e.g. debugserver on Darwin), we can watch any power-of-2 size region of memory up to 2GB, aligned to that same size. I updated the Watchpoint constructor and CommandObjectWatchpoint to create a CompilerType of Array<UInt8> when the size of the watched region is greater than pointer-size and we don't have a variable type to use. For pointer-size and smaller, we can display the watched granule as an integer value; for larger-than-pointer-size we will display as an array of bytes. I have watchpoint list now print the WatchpointResources used to implement the watchpoint. I added a WatchpointAlgorithm class which has a top-level static method that takes an enum flag mask WatchpointHardwareFeature and a user address and size, and returns a vector of WatchpointResources covering the request. It does not take into account the number of watchpoint registers the target has, or the number still available for use. Right now there is only one algorithm, which monitors power-of-2 regions of memory. For up to pointer-size, this is what Intel hardware supports. AArch64 Byte Address Select watchpoints can watch any number of contiguous bytes in a pointer-size memory granule, that is not currently supported so if you ask to watch bytes 3-5, the algorithm will watch the entire doubleword (8 bytes). The newly default "modify" style means we will silently ignore modifications to bytes outside the watched range. I've temporarily skipped TestLargeWatchpoint.py for all targets. It was only run on Darwin when using the in-tree debugserver, which was a proxy for "debugserver supports MASK watchpoints". I'll be adding the aforementioned feature flag from the stub and enabling full mask watchpoints when a debugserver with that feature is enabled, and re-enable this test. I added a new TestUnalignedLargeWatchpoint.py which only has one test but it's a great one, watching a 22-byte range that is unaligned and requires four 8-byte watchpoints to cover. I also added a unit test, WatchpointAlgorithmsTests, which has a number of simple tests against WatchpointAlgorithms::PowerOf2Watchpoints. I think there's interesting possible different approaches to how we cover these; I note in the unit test that a user requesting a watch on address 0x12e0 of 120 bytes will be covered by two watchpoints today, a 128-bytes at 0x1280 and at 0x1300. But it could be done with a 16-byte watchpoint at 0x12e0 and a 128-byte at 0x1300, which would have fewer false positives/private stops. As we try refining this one, it's helpful to have a collection of tests to make sure things don't regress. I tested this on arm64 macOS, (genuine) x86_64 macOS, and AArch64 Ubuntu. I have not modifed the Windows process plugins yet, I might try that as a standalone patch, I'd be making the change blind, but the necessary changes (see ProcessGDBRemote::EnableWatchpoint) are pretty small so it might be obvious enough that I can change it and see what the Windows CI thinks. There isn't yet a packet (or a qSupported feature query) for the gdb remote serial protocol stub to communicate its watchpoint capabilities to lldb. I'll be doing that in a patch right after this is landed, having debugserver advertise its capability of AArch64 MASK watchpoints, and have ProcessGDBRemote add eWatchpointHardwareArmMASK to WatchpointAlgorithms so we can watch larger than 32-byte requests on Darwin. I haven't yet tackled WatchpointResource *sharing* by multiple Watchpoints. This is all part of the goal, especially when we may be watching a larger memory range than the user requested, if they then add another watchpoint next to their first request, it may be covered by the same WatchpointResource (hardware watchpoint register). Also one "read" watchpoint and one "write" watchpoint on the same memory granule need to be handled, making the WatchpointResource cover all requests. As WatchpointResources aren't shared among multiple Watchpoints yet, there's no handling of running the conditions/commands/etc on multiple Watchpoints when their shared WatchpointResource is hit. The goal beyond "large watchpoint" is to unify (much more) the Watchpoint and Breakpoint behavior and commands. I have a feeling I may be slowly chipping away at this for a while. Re-landing this patch after fixing two undefined behaviors in WatchpointAlgorithms found by UBSan and by failures on different CI bots. rdar://108234227 | 2 年前 | |
[lldb] [mostly NFC] Large WP foundation: WatchpointResources (#68845) This patch is rearranging code a bit to add WatchpointResources to Process. A WatchpointResource is meant to represent a hardware watchpoint register in the inferior process. It has an address, a size, a type, and a list of Watchpoints that are using this WatchpointResource. This current patch doesn't add any of the features of WatchpointResources that make them interesting -- a user asking to watch a 24 byte object could watch this with three 8 byte WatchpointResources. Or a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte at 0x1003, these must both be served by a single WatchpointResource on that doubleword at 0x1000 on a 64-bit target, if two hardware watchpoint registers were used to track these separately, one of them may not be hit. Or if you have one Watchpoint on a variable with a condition set, and another Watchpoint on that same variable with a command defined or different condition, or ignorecount, both of those Watchpoints need to evaluate their criteria/commands when their WatchpointResource has been hit. There's a bit of code movement to rearrange things in the direction I'll need for implementing this feature, so I want to start with reviewing & landing this mostly NFC patch and we can focus on the algorithmic choices about how WatchpointResources are shared and handled as they're triggeed, separately. This patch also stops printing "Watchpoint <n> hit: old value: <x>, new vlaue: <y>" for Read watchpoints. I could make an argument for print "Watchpoint <n> hit: current value <x>" but the current output doesn't make any sense, and the user can print the value if they are particularly interested. Read watchpoints are used primarily to understand what code is reading a variable. This patch adds more fallbacks for how to print the objects being watched if we have types, instead of assuming they are all integral values, so a struct will print its elements. As large watchpoints are added, we'll be doing a lot more of those. To track the WatchpointSP in the WatchpointResources, I changed the internal API which took a WatchpointSP and devolved it to a Watchpoint*, which meant touching several different Process files. I removed the watchpoint code in ProcessKDP which only reported that watchpoints aren't supported, the base class does that already. I haven't yet changed how we receive a watchpoint to identify the WatchpointResource responsible for the trigger, and identify all Watchpoints that are using this Resource to evaluate their conditions etc. This is the same work that a BreakpointSite needs to do when it has been tiggered, where multiple Breakpoints may be at the same address. There is not yet any printing of the Resources that a Watchpoint is implemented in terms of ("watchpoint list", or SBWatchpoint::GetDescription). "watchpoint set var" and "watchpoint set expression" take a size argument which was previously 1, 2, 4, or 8 (an enum). I've changed this to an unsigned int. Most hardware implementations can only watch 1, 2, 4, 8 byte ranges, but with Resources we'll allow a user to ask for different sized watchpoints and set them in hardware-expressble terms soon. I've annotated areas where I know there is work still needed with LWP_TODO that I'll be working on once this is landed. I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS. https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116 (cherry picked from commit fc6b72523f3d73b921690a713e97a433c96066c6) | 2 年前 | |
[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 年前 | |
[Breakpoint] Remove redundant member initialization (NFC) Identified with readability-redundant-member-init. | 4 年前 | |
Remove hardware index from watchpoints and breakpoints (#72012) The Watchpoint and Breakpoint objects try to track the hardware index that was used for them, if they are hardware wp/bp's. The majority of our debugging goes over the gdb remote serial protocol, and when we set the watchpoint/breakpoint, there is no (standard) way for the remote stub to communicate to lldb which hardware index was used. We have an lldb-extension packet to query the total number of watchpoint registers. When a watchpoint is hit, there is an lldb extension to the stop reply packet (documented in lldb-gdb-remote.txt) to describe the watchpoint including its actual hardware index, <addr within wp range> <wp hw index> <actual accessed address> (the third field is specifically needed for MIPS). At this point, if the stub reported these three fields (the stub is only required to provide the first), we can know the actual hardware index for this watchpoint. Breakpoints are worse; there's never any way for us to be notified about which hardware index was used. Breakpoints got this as a side effect of inherting from StoppointSite with Watchpoints. We expose the watchpoint hardware index through "watchpoint list -v" and through SBWatchpoint::GetHardwareIndex. With my large watchpoint support, there is no *single* hardware index that may be used for a watchpoint, it may need multiple resources. Also I don't see what a user is supposed to do with this information, or an IDE. Knowing the total number of watchpoint registers on the target, and knowing how many Watchpoint Resources are currently in use, is helpful. Knowing how many Watchpoint Resources a single user-specified watchpoint needed to be implemented is useful. But knowing which registers were used is an implementation detail and not available until we hit the watchpoint when using gdb remote serial protocol. So given all that, I'm removing watchpoint hardware index numbers. I'm changing the SB API to always return -1. | 2 年前 | |
Convert ValueObject::Dump() to return llvm::Error() (NFCish) This change by itself has no measurable effect on the LLDB testsuite. I'm making it in preparation for threading through more errors in the Swift language plugin. | 2 年前 | |
[lldb] Add QSupported key to report watchpoint types supported (#80376) debugserver on arm64 devices can manage both Byte Address Select watchpoints (1-8 bytes) and MASK watchpoints (8 bytes-2 gigabytes). This adds a SupportedWatchpointTypes key to the QSupported response from debugserver with a list of these, so lldb can take full advantage of them when creating larger regions with a single hardware watchpoint. Also add documentation for this, and two other lldb extensions, to the lldb-gdb-remote.txt documentation. Re-enable TestLargeWatchpoint.py on Darwin systems when testing with the in-tree built debugserver. I can remove the "in-tree built debugserver" in the future when this new key is handled by an Xcode debugserver. | 2 年前 | |
[lldb][NFCI] Remove EventData* param from BroadcastEvent (#78773) BroadcastEvent currently takes its EventData* param and shoves it into an Event object, which takes ownership of the pointer and places it into a shared_ptr to manage the lifetime. Instead of relying on new and passing raw pointers around, I think it would make more sense to create the shared_ptr up front. | 2 年前 | |
[Breakpoint] Remove redundant member initialization (NFC) Identified with readability-redundant-member-init. | 4 年前 | |
[lldb] NFC fixes addressing David's feedback David Spickett had several suggestions for https://github.com/llvm/llvm-project/pull/79962 after I'd already merged it. Address those. | 2 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 个月前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 1 个月前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 2 年前 |