Changes in TestUnalignedLargeWatchpoint.py

7dd790db8b77c4a833c06632e903dc4f13877a64 - [lldb] NFC fixes addressing David's feedback

Fri, 02 Feb 2024 03:17:05 +0000

[lldb] NFC fixes addressing David's feedbackDavid Spickett had several suggestions forhttps://github.com/llvm/llvm-project/pull/79962 after I'dalready merged it. Address those. List of files: /llvm-project/lldb/test/API/functionalities/watchpoint/unaligned-large-watchpoint/TestUnalignedLargeWatchpoint.py

147d7a64f8493e78669581097a3ff06c985aa3a1 - [lldb] Add support for large watchpoints in lldb (#79962)

Thu, 01 Feb 2024 05:01:59 +0000

[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/72116This patch breaks a user's watchpoint into one or moreWatchpointResources which reflect what the hardware registers can cover.This means we can watch objects larger than 8 bytes, and we can watchedunaligned address ranges. On a typical 64-bit target with 4 watchpointregisters you can watch 32 bytes of memory if the start address isdoubleword aligned.Additionally, if the remote stub implements AArch64 MASK stylewatchpoints (e.g. debugserver on Darwin), we can watch any power-of-2size region of memory up to 2GB, aligned to that same size.I updated the Watchpoint constructor and CommandObjectWatchpoint tocreate a CompilerType of Array when the size of the watchedregion is greater than pointer-size and we don't have a variable type touse. For pointer-size and smaller, we can display the watched granule asan integer value; for larger-than-pointer-size we will display as anarray of bytes.I have `watchpoint list` now print the WatchpointResources used toimplement the watchpoint.I added a WatchpointAlgorithm class which has a top-level static methodthat takes an enum flag mask WatchpointHardwareFeature and a useraddress and size, and returns a vector of WatchpointResources coveringthe request. It does not take into account the number of watchpointregisters the target has, or the number still available for use. Rightnow there is only one algorithm, which monitors power-of-2 regions ofmemory. For up to pointer-size, this is what Intel hardware supports.AArch64 Byte Address Select watchpoints can watch any number ofcontiguous bytes in a pointer-size memory granule, that is not currentlysupported so if you ask to watch bytes 3-5, the algorithm will watch theentire doubleword (8 bytes). The newly default "modify" style means wewill silently ignore modifications to bytes outside the watched range.I've temporarily skipped TestLargeWatchpoint.py for all targets. It wasonly run on Darwin when using the in-tree debugserver, which was a proxyfor "debugserver supports MASK watchpoints". I'll be adding theaforementioned feature flag from the stub and enabling full maskwatchpoints when a debugserver with that feature is enabled, andre-enable this test.I added a new TestUnalignedLargeWatchpoint.py which only has one testbut it's a great one, watching a 22-byte range that is unaligned andrequires four 8-byte watchpoints to cover.I also added a unit test, WatchpointAlgorithmsTests, which has a numberof simple tests against WatchpointAlgorithms::PowerOf2Watchpoints. Ithink there's interesting possible different approaches to how we coverthese; I note in the unit test that a user requesting a watch on address0x12e0 of 120 bytes will be covered by two watchpoints today, a128-bytes at 0x1280 and at 0x1300. But it could be done with a 16-bytewatchpoint at 0x12e0 and a 128-byte at 0x1300, which would have fewerfalse positives/private stops. As we try refining this one, it's helpfulto have a collection of tests to make sure things don't regress.I tested this on arm64 macOS, (genuine) x86_64 macOS, and AArch64Ubuntu. I have not modifed the Windows process plugins yet, I might trythat as a standalone patch, I'd be making the change blind, but thenecessary changes (see ProcessGDBRemote::EnableWatchpoint) are prettysmall so it might be obvious enough that I can change it and see whatthe Windows CI thinks.There isn't yet a packet (or a qSupported feature query) for the gdbremote serial protocol stub to communicate its watchpoint capabilitiesto 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 toWatchpointAlgorithms so we can watch larger than 32-byte requests onDarwin.I haven't yet tackled WatchpointResource *sharing* by multipleWatchpoints. This is all part of the goal, especially when we may bewatching a larger memory range than the user requested, if they then addanother watchpoint next to their first request, it may be covered by thesame WatchpointResource (hardware watchpoint register). Also one "read"watchpoint and one "write" watchpoint on the same memory granule need tobe 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 multipleWatchpoints when their shared WatchpointResource is hit. The goal beyond"large watchpoint" is to unify (much more) the Watchpoint and Breakpointbehavior and commands. I have a feeling I may be slowly chipping away atthis for a while.Re-landing this patch after fixing two undefined behaviors inWatchpointAlgorithms found by UBSan and by failures on differentCI bots.rdar://108234227 List of files: /llvm-project/lldb/test/API/functionalities/watchpoint/unaligned-large-watchpoint/TestUnalignedLargeWatchpoint.py

57c66b35a885b571f9897d75d18f1d974c29e533 - [lldb] Add support for large watchpoints in lldb (#79962)

Wed, 31 Jan 2024 17:40:50 +0000

[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 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. rdar://108234227 List of files: /llvm-project/lldb/test/API/functionalities/watchpoint/unaligned-large-watchpoint/TestUnalignedLargeWatchpoint.py