[Lldb-commits] [PATCH] D134037: [lldb] Fix CommandInterpreter::DidProcessStopAbnormally() with multiple threads

[Martin Storsjö via Phabricator via lldb-commits]

mstorsjo added a comment.

In D134037#3815240 <https://reviews.llvm.org/D134037#3815240>, @DavidSpickett wrote:

>> I might add the AArch64 and Arm equivalent if I have some spare time.
>
> I looked into this and there's a detail that makes this work on x86 only. So I'll leave it as is, it's getting tested somewhere, and that's what matters.
>
> If you're curious this is the spanner in the works:
>
>   size_t NativeProcessProtocol::GetSoftwareBreakpointPCOffset() {
>     switch (GetArchitecture().GetMachine()) {
>     case llvm::Triple::x86:
>     case llvm::Triple::x86_64:
>     case llvm::Triple::systemz:
>       // These architectures report increment the PC after breakpoint is hit.
>       return cantFail(GetSoftwareBreakpointTrapOpcode(0)).size();
>
> Meaning AArch64 doesn't. lldb on x86 can continue past a break in the program because of this:
>
>   (lldb) run
>   Process 31032 launched: '/tmp/test.o' (x86_64)
>   Process 31032 stopped
>   * thread #1, name = 'test.o', stop reason = signal SIGTRAP
>       frame #0: 0x000055555555460f test.o`main at test.c:3
>      1    int main() {
>      2            __asm__ __volatile__("int3");
>   -> 3                  return 0;
>      4    }
>   (lldb) c
>   Process 31032 resuming
>   Process 31032 exited with status = 0 (0x00000000)
>
> On AArch64 we just stick on the break:
>
>   (lldb) run
>   Process 2162869 launched: '/tmp/test.o' (aarch64)
>   Process 2162869 stopped
>   * thread #1, name = 'test.o', stop reason = signal SIGTRAP
>       frame #0: 0x0000aaaaaaaaa71c test.o`main at test.c:2:3
>      1    int main() {
>   -> 2      asm volatile("brk #0xf000\n\t");
>      3      return 0;
>      4    }
>   (lldb) c
>   Process 2162869 resuming
>   Process 2162869 stopped
>   * thread #1, name = 'test.o', stop reason = signal SIGTRAP
>       frame #0: 0x0000aaaaaaaaa71c test.o`main at test.c:2:3
>      1    int main() {
>   -> 2      asm volatile("brk #0xf000\n\t");
>      3      return 0;
>      4    }
>
> gdb has the same behaviour on AArch64 so I'll leave it as is until someone complains.

Ah, yes, I remember hitting that issue occasionally. On the other hand, if it would be somewhat doable to fix it, it'd would be a great value add IMO - I've had to do acrobatics to set the program counter to the next instruction to resume running after such a breakpoint a couple times...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134037/new/

https://reviews.llvm.org/D134037