[Lldb-commits] [lldb] Reapply "[lldb] Implement basic support for reverse-continue (#125242)" (again) (PR #128156)

Tue Mar 18 06:01:27 PDT 2025

labath wrote:

> Let me know what other info might be useful

It would be useful to know if you can reproduce this problem locally (because I can't -- the test passes on my mac). If you can't then it would be useful to get as much information about this buildbot as possible (what kind of debugserver it uses, OS versions and such), as it means there's something different about it.

> On Linux ARM64 both gdb and lldb seem to adjust the hardware behavior so that single-stepping an instruction that fires a watchpoint leaves the PC pointing to the next instruction.
> 
> Maybe this is not true on Mac? I can't test that myself.

It works the same way on a mac. And the behavior is implemented on the client (it disables the watchpoint, single-steps, and then re-enables the watchpoint). I'm not entirely sure what happens (or what should happen) when running backwards to the watchpoint. 

One more (possibly irrelevant) note: On lldb, this behavior is actually controlled by the `watchpoint_exceptions_received:before/after` response to the `qHostInfo` packet, which allows to to work with an "x86" machine which has the "arm" exception behavior (and vice versa). While somewhat weird, this is very handy when working with emulators, as it avoids the need to simulate the arm exception behavior on x86 (which is quite hard).

> So I wonder whether, in normal operation on the test system, singlestepping an instruction which triggers a watchpoint actually reports the watchpoint being hit.

This definitely works (on my machine). Here's the relevant part of the log:
```
<lldb.process.gdb-remote.async>  <  18> send packet: $vCont;s:2d3138#57
<lldb.process.gdb-remote.async>  <1093> read packet: $T00thread:2d3138;threads:2d3138;thread-pcs:100003f88;00:0100000000000000;01:20f8df6f01000000;02:30f8df6f01000000;03:18f9df6f01000000;04:0100000000000000;05:0000000000000000;06:0000000000000000;07:200d000000000000;08:0600000000000000;09:50c149f701000000;0a:10f5de6f01000000;0b:60f5df6f01000000;0c:b011000000000000;0d:0040000001000000;0e:0040000000000000;0f:55af9a9b01000000;10:a4bfdf8d01000000;11:e0afd7ff01000000;12:0000000000000000;13:50c049f701000000;14:a0c049f701000000;15:50c049f701000000;16:b8f6df6f01000000;17:b8f6df6f01000000;18:0020a48d01000000;19:0000000000000000;1a:0000000000000000;1b:0000000000000000;1c:0000000000000000;1d:00f8df6f01000000;1e:7482a48d01000000;1f:c0f5df6f01000000;20:883f000001000000;21:00102060;a1:c8f5df6f01000000;a2:620000d2;a3:00000000;reason:watchpoint;description:3631373139313537323020302036313731393135373230;watch_addr:16fdff5c8;me_watch_addr:16fdff5c8;wp_hw_idx:0;wp_esr_iss:62;wp_esr_wpt:0;wp_esr_wptv:0;wp_esr_wpf:0;wp_esr_fnp:0;wp_esr_vncr:0;wp_esr_fnv:0;wp_esr_cm:1;wp_esr_wnr:1;wp_esr_dfsc:22;memory:0x16fdff800=00000000000000000000000000000000;#00
<lldb.process.internal-state(pid=24579)>         <  18> send packet: $z2,16fdff5c8,4#05
<lldb.process.internal-state(pid=24579)>         <   6> read packet: $OK#00
<lldb.process.gdb-remote.async>  <  18> send packet: $vCont;s:2d3138#57
<lldb.process.gdb-remote.async>  < 862> read packet: $T05thread:2d3138;threads:2d3138;thread-pcs:100003f8c;00:0100000000000000;01:20f8df6f01000000;02:30f8df6f01000000;03:18f9df6f01000000;04:0100000000000000;05:0000000000000000;06:0000000000000000;07:200d000000000000;08:0600000000000000;09:50c149f701000000;0a:10f5de6f01000000;0b:60f5df6f01000000;0c:b011000000000000;0d:0040000001000000;0e:0040000000000000;0f:55af9a9b01000000;10:a4bfdf8d01000000;11:e0afd7ff01000000;12:0000000000000000;13:50c049f701000000;14:a0c049f701000000;15:50c049f701000000;16:b8f6df6f01000000;17:b8f6df6f01000000;18:0020a48d01000000;19:0000000000000000;1a:0000000000000000;1b:0000000000000000;1c:0000000000000000;1d:00f8df6f01000000;1e:7482a48d01000000;1f:c0f5df6f01000000;20:8c3f000001000000;21:00100060;a1:0000000000000000;a2:220000cb;a3:00000000;metype:6;mecount:2;medata:1;medata:0;memory:0x16fdff800=00000000000000000000000000000000;#00
<lldb.process.internal-state(pid=24579)>         <  18> send packet: $Z2,16fdff5c8,4#e5
<lldb.process.internal-state(pid=24579)>         <   6> read packet: $OK#00
lldb.debugger.event-handler      <  16> send packet: $jThreadsInfo#c1
lldb.debugger.event-handler      <1111> read packet: $[{"tid":2961720,"metype":6,"medata":[1,0],"reason":"exception","qaddr":8446511552,"associated_with_dispatch_queue":true,"dispatch_queue_t":8446526400,"qname":"com.apple.main-thread","qkind":"serial","qserialnum":1,"registers":{"0":"0100000000000000","1":"20f8df6f01000000","2":"30f8df6f01000000","3":"18f9df6f01000000","4":"0100000000000000","5":"0000000000000000","6":"0000000000000000","7":"200d000000000000","8":"0600000000000000","9":"50c149f701000000","10":"10f5de6f01000000","11":"60f5df6f01000000","12":"b011000000000000","13":"0040000001000000","14":"0040000000000000","15":"55af9a9b01000000","16":"a4bfdf8d01000000","17":"e0afd7ff01000000","18":"0000000000000000","19":"50c049f701000000","20":"a0c049f701000000","21":"50c049f701000000","22":"b8f6df6f01000000","23":"b8f6df6f01000000","24":"0020a48d01000000","25":"0000000000000000","26":"0000000000000000","27":"0000000000000000","28":"0000000000000000","29":"00f8df6f01000000","30":"7482a48d01000000","31":"c0f5df6f01000000","32":"8c3f000001000000","33":"00100060"}],"memory":[{"address":6171916288,"bytes":"00000000000000000000000000000000"}]]}]]#00
lldb.debugger.event-handler      <  18> send packet: $z2,16fdff5c8,4#05
lldb.debugger.event-handler      <   6> read packet: $OK#00
lldb.debugger.event-handler      <  18> send packet: $x16fdff400,200#c7
lldb.debugger.event-handler      < 516> read packet: $000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c0970d00000000000000000000000000c0978d01000000010000000000000050c049f7010000000100000000000000c0f5df6f010000006000a78d0100000000000000000000000000000000000000120000011a000000c41fe5000000000080c349f7010000000000000001000000000000000000000000000000000000000020a48d01000000b8f6df6f01000000c0f5df6f010000003cfca68d01000000a0c049f70100000050c049f70100000000f8df6f010000000600000000000000000000000000000000000000000000000000000000000000a0c049f70100000028f6df6f0100000030f6df6f01000000#00

Watchpoint 1 hit:
old value: 5
new value: 6
lldb.debugger.event-handler      <  18> send packet: $Z2,16fdff5c8,4#e5
lldb.debugger.event-handler      <   6> read packet: $OK#00
lldb.debugger.event-handler      < 216> send packet: $jThreadExtendedInfo:{"dti_qos_class_index":4,"dti_queue_index":20,"dti_voucher_index":28,"plo_pthread_tsd_base_address_offset":0,"plo_pthread_tsd_base_offset":224,"plo_pthread_tsd_entry_size":8,"thread":2961720}]#fd
lldb.debugger.event-handler      < 200> read packet: ${"tsd_address":8446511392,"requested_qos":{"enum_value":33,"constant_name":"QOS_CLASS_USER_INTERACTIVE","printable_name":"User Interactive"}],"pthread_t":8446511168,"dispatch_queue_t":8446526400}]#00
```

Interestingly, the first step operation is reported as `reason:watchpoint` and only the second step (when the watchpoint is disabled) returns mach exception data. I don't exactly know what this means, but it feels relevant.

I'm doing a fresh build of lldb now and I'm going to post the results of my test run for comparison.

https://github.com/llvm/llvm-project/pull/128156