Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[lldb] Add 'modify' type watchpoints, make it default (#66308) #7499

Merged

Conversation

jasonmolenda
Copy link

[lldb] Add 'modify' type watchpoints, make it default (llvm#66308)

Watchpoints in lldb can be either 'read', 'write', or 'read/write'. This is exposing the actual behavior of hardware watchpoints. gdb has a different behavior: a "write" type watchpoint only stops when the watched memory region changes.

A user is using a watchpoint for one of three reasons:

  1. Want to find what is changing/corrupting this memory.
  2. Want to find what is writing to this memory.
  3. Want to find what is reading from this memory.

I believe (1) is the most common use case for watchpoints, and it currently can't be done in lldb -- the user needs to continue every time the same value is written to the watched-memory manually. I think gdb's behavior is the correct one. There are some use cases where a developer wants to find every function that writes/reads to/from a memory region, regardless of value, I want to still allow that functionality.

This is also a bit of groundwork for my large watchpoint support proposal
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116 where I will be adding support for AArch64 MASK watchpoints which watch power-of-2 memory regions. A user might ask to watch 24 bytes, and a MASK watchpoint stub can do this with a 32-byte MASK watchpoint if it is properly aligned. And we need to ignore writes to the final 8 bytes of that watched region, and not show those hits to the user.

This patch adds a new 'modify' watchpoint type and it is the default.

Re-landing this patch after addressing testsuite failures found in CI on Linux, Intel machines, and windows.

rdar://108234227
(cherry picked from commit 933ad5c)

Watchpoints in lldb can be either 'read', 'write', or 'read/write'. This
is exposing the actual behavior of hardware watchpoints. gdb has a
different behavior: a "write" type watchpoint only stops when the
watched memory region *changes*.

A user is using a watchpoint for one of three reasons:

1. Want to find what is changing/corrupting this memory.
2. Want to find what is writing to this memory.
3. Want to find what is reading from this memory.

I believe (1) is the most common use case for watchpoints, and it
currently can't be done in lldb -- the user needs to continue every time
the same value is written to the watched-memory manually. I think gdb's
behavior is the correct one. There are some use cases where a developer
wants to find every function that writes/reads to/from a memory region,
regardless of value, I want to still allow that functionality.

This is also a bit of groundwork for my large watchpoint support
proposal
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
where I will be adding support for AArch64 MASK watchpoints which watch
power-of-2 memory regions. A user might ask to watch 24 bytes, and a
MASK watchpoint stub can do this with a 32-byte MASK watchpoint if it is
properly aligned. And we need to ignore writes to the final 8 bytes of
that watched region, and not show those hits to the user.

This patch adds a new 'modify' watchpoint type and it is the default.

Re-landing this patch after addressing testsuite failures found in CI on
Linux, Intel machines, and windows.

rdar://108234227
(cherry picked from commit 933ad5c)
@jasonmolenda jasonmolenda merged commit d926114 into swiftlang:stable/20230725 Sep 20, 2023
@jasonmolenda jasonmolenda deleted the cp/modify-watchpoints branch September 20, 2023 22:12
@jasonmolenda jasonmolenda restored the cp/modify-watchpoints branch September 20, 2023 22:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant