[Lldb-commits] [PATCH] D25057: Fix ARM/AArch64 Step-Over watchpoint issue remove provision for duplicate watchpoints

Pavel Labath via lldb-commits lldb-commits at lists.llvm.org
Thu Oct 20 03:12:00 PDT 2016


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 <jingham at apple.com> wrote:
>
>> On Oct 4, 2016, at 9:28 AM, Pavel Labath via lldb-commits <lldb-commits at 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
>


More information about the lldb-commits mailing list