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