LLDB seem to deadloop upon hitting AArch64 trap asm (brk #0xf000)

[mgorny]

lldb/test/API/tools/lldb-server/main.cpp defines the following trap code for aarch64:

   145 	#elif defined(__aarch64__)
-> 146 	  asm volatile("brk #0xf000");

However, this seems to deadloop LLDB. E.g.:

$ ./bin/lldb lldb-test-build.noindex/tools/lldb-server/TestGdbRemoteFork.test_c_child_llgs/a.out trap
(lldb) target create "lldb-test-build.noindex/tools/lldb-server/TestGdbRemoteFork.test_c_child_llgs/a.out"
Current executable set to '/home/mgorny/llvm-project/build/lldb-test-build.noindex/tools/lldb-server/TestGdbRemoteFork.test_c_child_llgs/a.out' (aarch64).
(lldb) settings set -- target.run-args  "trap"
(lldb) run
Process 2869341 launched: '/home/mgorny/llvm-project/build/lldb-test-build.noindex/tools/lldb-server/TestGdbRemoteFork.test_c_child_llgs/a.out' (aarch64)
Process 2869341 stopped
* thread #1, name = 'a.out', stop reason = signal SIGTRAP
    frame #0: 0x0000aaaaaaaa4124 a.out`trap() at main.cpp:146:3
   143 	#if defined(__x86_64__) || defined(__i386__)
   144 	  asm volatile("int3");
   145 	#elif defined(__aarch64__)
-> 146 	  asm volatile("brk #0xf000");
   147 	#elif defined(__arm__)
   148 	  asm volatile("udf #254");
   149 	#elif defined(__powerpc__)
(lldb) cont
Process 2869341 resuming
Process 2869341 stopped
* thread #1, name = 'a.out', stop reason = signal SIGTRAP
    frame #0: 0x0000aaaaaaaa4124 a.out`trap() at main.cpp:146:3
   143 	#if defined(__x86_64__) || defined(__i386__)
   144 	  asm volatile("int3");
   145 	#elif defined(__aarch64__)
-> 146 	  asm volatile("brk #0xf000");
   147 	#elif defined(__arm__)
   148 	  asm volatile("udf #254");
   149 	#elif defined(__powerpc__)

and so on.

[llvmbot]

@llvm/issue-subscribers-lldb

[labath]

That is sort of "working as intended" because arm cpus (unlike intel) do not increment the pc upon hitting the breakpoint instruction. We probably need to paper over that in our tests.

[labath]

(i.e. increment the pc manually)

[mgorny]

What about running that program with LLDB? Should the user manually increment PC as well?

[mgorny]

Wrt the test, perhaps the simplest solution would be to add another CLI command to raise(SIGSTOP)? These tests are POSIX-only anyway, so I suppose that would work for us, wouldn't it?

[labath]

What about running that program with LLDB? Should the user manually increment PC as well?

Well... that's what he has to do right now. There's a conflict here between wanting to preserve the cpu/os behavior for consistency with the non-debugging scenario, and being helpful and doing what the user wants (which is contingent on being able to guess what the user wants).

The last time this subject came up, someone floated the idea of automatically adjusting the PC inside lldb, but only right before a resume, and only if the user hasn't done something funny (e.g. change the pc manually). I think this could strike a good balance between helpfulness and non-interference, but it's all vapourware right now. It also doesn't help us with the problem at hand.

Wrt the test, perhaps the simplest solution would be to add another CLI command to raise(SIGSTOP)? These tests are POSIX-only anyway, so I suppose that would work for us, wouldn't it?

Yeah, I suppose that could work. It won't solve the problem with in the general case, as I would like to be able to use this pattern for other tests too. However, I seem to recall something about the windows OS fixing up the PC in this situations, so maybe the existing solution will actually work there (and all we would need to paper over is the difference in signal numbers).

[jasonmolenda]

I handled this one poorly on Darwin systems by doing it in debugserver. brk #0xf000 is used for builtin_debugtrap() which is intended to trap into the debugger and allow you to resume execution. I did

commit 92b036dea24b6e7ebfd950facdbf5543135eda05
Author: Jason Molenda <jason@molenda.com>
Date:   Thu Nov 12 23:28:24 2020 -0800

    debugserver should advance pc past builtin_debugtrap insn

wherein I comment that I'm a scoundrel,

+    // Generally speaking, this knowledge should be centralized in lldb, 
+    // recognizing the builtin_trap instruction and knowing how to advance
+    // the pc past it, so that continue etc work.

but didn't figure out how to push a thread plan to advance over the break, I'm not sure if I spoke with @jimingham about it before I decided to do this in debugserver. There's an API test for it, TestBuiltinDebugTrap.py, but it's only run on Darwin systems.

[jasonmolenda]

I'm not sure if this is really even a ThreadPlan situation. We need to show the original pc value as the location we stopped, so the builtin_trap() line in the source is highlighted, but as soon as we resume execution we need to pc += 4 before that thread runs. a ThreadPlan pushed on the stack makes sense, but it's a threadplan that would increment pc and be completed - a bit unusual. And I'm not sure where to locate the instruction comparison when we've stopped, it's target architecture specific. Perf wise, we should be able to read the instruction out of the binary instead of live memory, otherwise we'd be imposing a memory read at each stop and it would be very expensive.

[jimingham]

lldb handles stepping over a breakpoint with the ThreadPlanStepOverBreakpoint. However, because lldb has to handle the case where we stopped, e.g. for a step, then the user puts a breakpoint on the current PC before continuing, right before it restarts the process, it looks at all the threads, and if there's one that's sitting on a breakpoint, it pushes the "ThreadPlanStepOverBreakpoint" to handle the step. You could add to the "am I at a breakpoint" detection at the same point. It's a little weird to have a thread plan that gets done w/o running the target, and maybe that's overkill. You could just always first check for the trap & move the PC before doing the "am I at a breakpoint" detection. If you wanted to use a thread plan, however, the step-in thread plan does do "fake step-in's" when it's stopped somewhere where multiple levels of inlining share the same PC. Then it just increments the inline step depth and says it's done without actually running the process. So you could emulate that behavior. Jim

…

On Jun 28, 2022, at 11:53 AM, Jason Molenda ***@***.***> wrote: I'm not sure if this is really even a ThreadPlan situation. We need to show the original pc value as the location we stopped, so the builtin_trap() line in the source is highlighted, but as soon as we resume execution we need to pc += 4 before that thread runs. a ThreadPlan pushed on the stack makes sense, but it's a threadplan that would increment pc and be completed - a bit unusual. And I'm not sure where to locate the instruction comparison when we've stopped, it's target architecture specific. Perf wise, we should be able to read the instruction out of the binary instead of live memory, otherwise we'd be imposing a memory read at each stop and it would be very expensive. — Reply to this email directly, view it on GitHub <#56268 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADUPVW3RLL3KIMPTG2CF6WLVRNCY7ANCNFSM52CJNTLQ>. You are receiving this because you were mentioned.

[jasonmolenda]

Yeah, handling this in debugserver was a simple approach because I could have debugserver report the original pc value but, behind lldb's back, update the thread's pc value to be pc+4, so when we resume, it does the right thing. Inside lldb, we don't have a great way to do the same thing, and need to defer the update to the point where we resume.

I guess one possible idea might be that we distinguish between a PC and a PC-for-symbolication pretty consistently across lldb. Both values are normally $pc on a live frame, and up the stack the PC-for-symbolication is $pc-1. But we could have lldb do pc += 4 and return the original pc value in PC-for-symbolication. You'd get the case where calling SBFrame::GetPC() returns one value, and then calling SBFrame::SymbolContext() etc would give you symbols that don't contain that pc (at least, likely, an SBLineEntry that doesn't contain that pc).

[mgorny]

I've decided to check how GDB/gdbserver is handling it… and it isn't. It just deadloops on the brk as well.