[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


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() {
    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
    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
->  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.


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