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