> On Aug 22, 2019, at 3:58 PM, Ismail Bennani via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > Hi Greg, > > Thanks for your suggestion! > >> On Aug 22, 2019, at 3:35 PM, Greg Clayton <clayb...@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@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 <pal...@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@lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > > Sincerely, > > Ismail > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
