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

[Greg Clayton via lldb-dev]

Another possibility is to have the IDE insert NOP opcodes for you when you write a breakpoint with a condition and compile NOPs into your program. 

So the flow is:
- set a breakpoint in IDE
- modify breakpoint to add a condition
- compile and debug, the IDE inserts NOP instructions at the right places
- now when you debug you have a NOP you can use and not have to worry about moving instructions


> On Aug 22, 2019, at 5:29 AM, Pedro Alves via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> 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
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev