[lldb-dev] [RFC] Fast Conditional Breakpoints (FCB)

[Pedro Alves via lldb-dev]

On 8/22/19 12:36 AM, Ismail Bennani via lldb-dev wrote:
>> On Aug 21, 2019, at 3:48 PM, Pedro Alves <palves at redhat.com> wrote:

>> Say, you're using a 5 bytes jmp instruction to jump to the
>> trampoline, so you need to replace 5 bytes at the breakpoint address.
>> But the instruction at the breakpoint address is shorter than
>> 5 bytes.  Like:
>>
>> ADDR | BEFORE           | AFTER
>> ---------------------------------------
>> 0000 | INSN1 (1 byte)   | JMP (5 bytes)
>> 0001 | INSN2 (2 bytes)  |                   <<< thread T's PC points here
>> 0002 |                  |
>> 0003 | INSN3 (2 bytes)  |
>>
>> Now once you resume execution, thread T is going to execute a bogus
>> instruction at ADDR 0001.
> 
> That’s a relevant point.
> 
> I haven’t thought of it, but I think this can be mitigated by checking at
> the time of replacing the instructions if any thread is within the copied
> instructions bounds.
> 
> If so, I’ll change all the threads' pcs that are in the critical region to
> point to new copied instruction location (inside the trampoline).
> 
> This way, it won’t change the execution flow of the program.

Yes, I think that would work, assuming that you can stop all threads, 
or all threads are already stopped, which I believe is true with
LLDB currently.  If any thread is running (like in gdb's non-stop mode)
then you can't do that, of course.

> 
> Thanks for pointing out this issue, I’ll make sure to add a fix to my
> implementation.
> 
> If you have any other suggestion on how to tackle this problem, I’d like
> really to know about it :).

Not off hand.  I think I'd take a look at Dyninst, see if they have
some sophisticated way to handle this scenario.

Thanks,
Pedro Alves