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. > - 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
