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

[Jason Molenda via lldb-dev]

> On Aug 22, 2019, at 3:58 PM, Ismail Bennani via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> Hi Greg,
> 
> Thanks for your suggestion!
> 
>> On Aug 22, 2019, at 3:35 PM, Greg Clayton <clayborg at gmail.com> 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
> 
> We’re trying to avoid rebuilding every time we want to debug, but I’ll keep
> this in mind as an eventual fallback.

It's also valuable to use FCBs on third party code.  You might want to put a FCB on dlopen(), strcmp'ing the first argument for a specific argument, without rebuilding the C libraries.  Recompilation/instrumentation makes this a lot simpler, but it also reduces the usefulness of the feature.


> 
>> - 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
>> 
> 
> Sincerely,
> 
> Ismail
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev