If you can rely on the IDE & compile&debug, you might as well made the IDE&compiler bake in the breakpoint condition and trompoline into the code without having to have the debugger build the trampoline afterwards.
Thanks, Pedro Alves On 8/22/19 11:35 PM, Greg Clayton 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 > - 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
