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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
