The reason you could not see this is that the issue is specific to arm
(or any target that reports watchpoint hits *before* executing the
instruction tripping the watch). In this case, we have special logic
in the client which removes the watchpoint, does a single step, and
reinstates the watchpoint. This code does not correctly handle the
case when you hit *another* watchpoint while "stepping over" the first
one.
I was not able to reproduce the exact original problem now (I was
doing it with one of Omair's previous changes applied, so it may not
be possible to reproduce on trunk), but here is another way this
problem manifests itself:
Process 6009 stopped
* thread #1: tid = 6009, 0xaac67324 a.out`main + 16 at a.c:2, name =
'a.out', stop reason = breakpoint 1.1
frame #0: 0xaac67324 a.out`main + 16 at a.c:2
1 int x;
-> 2 int main () { x = 47; return 0; }
(lldb) fr var &x
(int *) &x = 0xaac69004
(lldb) watchpoint set expression -s 1 -- 0xaac69004
Watchpoint created: Watchpoint 6: addr = 0xaac69004 size = 1 state =
enabled type = w
new value: 0
(lldb) watchpoint set expression -s 1 -- 0xaac69005
Watchpoint created: Watchpoint 7: addr = 0xaac69005 size = 1 state =
enabled type = w
new value: 0
(lldb) c
Process 6009 resuming
At this point, it appears as if the inferior keeps running and never
hits the watchpoint, but if you check the packet log you will see that
LLDB is continuously busy sending vCont packets trying to step over
the watchpoint hit.
Note that after Omair's change it will not be possible anymore to
reproduce the problem this easily, as he forbids the creation of
watchpoints within the same block, but you can reproduce still
reproduce it by having a signle instruction that writes to two blocks
(stp is a good candidate for that).
If you are more than curious and want to dig into that I can make a
better repro case for it.
pl
On 19 October 2016 at 18:34, Jim Ingham <jing...@apple.com> wrote:
>
>> On Oct 4, 2016, at 9:28 AM, Pavel Labath via lldb-commits
>> <lldb-commits@lists.llvm.org> wrote:
>>
>> Also, apparently lldb has a bug, where it mishandles the case where you do a
>> (user-level) single step over an instruction triggering a watchpoint. That
>> would be pretty important to fix as well.
>
> Do you have a reference for this? In a trivial case, it works correctly on
> MacOS so far as I can tell:
>
> (lldb) si
> Process 99358 stopped
> * thread #1: tid = 0x148d67e, function: main , stop reason = instruction step
> into
> frame #0: 0x0000000100000f5e changeit`main at changeit.c:9
> 6
> 7 printf("my_var is: %d.\n", my_var);
> 8
> -> 9 my_var = 20;
> 10
> 11 printf("my_var is: %d.\n", my_var);
> 12
> changeit`main:
> -> 0x100000f5e <+46>: movl $0x14, -0x8(%rbp)
> 0x100000f65 <+53>: movl -0x8(%rbp), %esi
> 0x100000f68 <+56>: movl %eax, -0xc(%rbp)
> 0x100000f6b <+59>: movb $0x0, %al
> (lldb) si
>
> Watchpoint 1 hit:
> old value: 10
> new value: 20
> Process 99358 stopped
> * thread #1: tid = 0x148d67e, function: main , stop reason = watchpoint 1
> frame #0: 0x0000000100000f65 changeit`main at changeit.c:11
> 8
> 9 my_var = 20;
> 10
> -> 11 printf("my_var is: %d.\n", my_var);
> 12
> 13 return 0;
> 14 }
> changeit`main:
> -> 0x100000f65 <+53>: movl -0x8(%rbp), %esi
> 0x100000f68 <+56>: movl %eax, -0xc(%rbp)
> 0x100000f6b <+59>: movb $0x0, %al
> 0x100000f6d <+61>: callq 0x100000f80 ; symbol stub for:
> printf
>
> Jim
>
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
