[lldb-dev] Continuing from dbgtrap on different targets
Joseph Tremoulet via lldb-dev
lldb-dev at lists.llvm.org
Wed Mar 4 12:16:22 PST 2020
Hi,
I'm noticing an unexpected difference between targets when I hit a dbgtrap in the debugger. Consider this simple llvm function:
define void @do_break() {
entry:
call void @llvm.debugtrap()
ret void
}
If I compile that with llc and use lldb to launch a program that calls it, on x86_64 linux (Ubuntu 18.04), here's what I see at the stop:
Process 130404 stopped
* thread #1, name = 'doit', stop reason = signal SIGTRAP
frame #0: 0x0000000000400541 doit`do_break at stub.ll:2:1
(lldb) disas
doit`do_break:
0x400540 <+0>: int3
-> 0x400541 <+1>: retq
(lldb) register read rip
rip = 0x0000000000400541 doit`do_break + 1 at stub.ll:2:1
Note that rip is reported as pointing to the next instruction after the int3. If I 'continue' from there, the program continues doing whatever was after the debugtrap.
If I follow the same steps on aarch64 (also Ubuntu 18.04), I see this:
Process 21586 stopped
* thread #1, name = 'doit', stop reason = signal SIGTRAP
frame #0: 0x00000000004005dc doit`do_break at stub.ll:1:1
(lldb) disas
doit`do_break:
-> 0x4005dc <+0>: brk #0x1
0x4005e0 <+4>: ret
(lldb) register read pc
pc = 0x00000000004005dc doit`do_break at stub.ll:1:1
Note that here, pc is reported as pointing at the 'brk' instruction itself. If I 'continue' from there, I immediately find myself stopped back at the same point, ad infinitum.
>From what I can tell, GDB also "gets stuck" when it hits this instruction on aarch64 (and also doesn't on x86_64).
I'm wondering what to make of this / where's the "bug".
* Should llvm use a different lowering for dbgtrap on aarch64-linux? I don't think so, it seems to be standard
* Should the system signal handler be reporting an incremented pc in the context struct when it hits brk?
* And even if so, what should the workaround be for systems without such a fix?
* Should lldb (and gdb for that matter) somehow recognize this case, and increment pc when stopping or resuming at a brk?
* Is this just unsupported, is continuing past a debugtrap UB or otherwise disallowed?
I'd appreciate any insights here.
Thanks,
-Joseph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20200304/2bb39dce/attachment.html>
More information about the lldb-dev
mailing list