breakpoint 5.1 之前就已经对 0x10838eaa8 这个地址下了 watch s exp -w w 内存写入断点，且在 c 之前，这块内存是没有值的。c 之后，通过之前预设的 breakpoint 6.1 断下来，再次查看，0x10838eaa8 这个位置就有值了。然而我的watchpoint并没有断下来。
大概的程序逻辑：
breakpoint 5.1 是 Dispatch_sync_C8893C8 函数调用的地址，这个时候 QWORD_77F2AA8 里还没有值。
breakpoint 6.1,就是 TAR_C8897F4() 里的地址，这个时候 QWORD_77F2AA8 里已经写入了目标数据的地址了。
本来想通过 watchpoint 来断到写入的代码，然后看看数据是怎么产生的，现在断不下来不清楚是啥原因。请大佬帮忙指教！
注意到之前的是在 thread-17 里面运行的，然后 dispatch 到 main-thread 里面去了，会是这个原因造成的吗？
那真不太清楚
因为本来可能的原因：watchpoint个数超过了硬件限制
但是你输出中已显示出，最多4个，你只有2个，所以没超过限制，不是这方面的原因。
其他可能，还真不了解。
等其他大佬帮你解决吧。
暂时只能贴出我之前的read的watchpoint：
(lldb) watchpoint set expression -w read -- 0x0000000103e79cb0
Watchpoint created: Watchpoint 1: addr = 0x103e79cb0 size = 8 state = enabled type = r
new value: 8223700941521445187
(lldb) watchpoint list
Number of supported hardware watchpoints: 4
Current watchpoints:
Watchpoint 1: addr = 0x103e79cb0 size = 8 state = enabled type = r
new value: 8223700941521445187
是work的：
Watchpoint 1 hit:
old value: 8223700941521445187
new value: 8223700941521445187
供参考。
不是个数的限制。重启调试过很多次，每次都只下了一个watch，也都断不下来。按理来说线程切换，应该也能断下来的才对，难道主线程有什么访问控制？还是有其他的什么反调试的机制。。太难搞了。