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

[Pedro Alves via lldb-dev]

If you can rely on the IDE & compile&debug, you might as well made the IDE&compiler
bake in the breakpoint condition and trompoline into the code without having to have
the debugger build the trampoline afterwards.

Thanks,
Pedro Alves

On 8/22/19 11:35 PM, Greg Clayton wrote:
> 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
>