Unable to continue after debug_break() on Fedora Linux under Parallels (both gdb + lldb)

[tim-rex]

While I seem able to use this library as intended on an M2 based mac with Xcode... I seem to be having trouble with both GDB and LLVM when running Fedora 38 under a Parallels based VM (arm64).

In both cases, debug_break() descends into an implementation of 'trap_instruction' that issues an appropriate breakpoint for aarch64 (.inst 0xd4200000)

In both cases, the breakpoint is caught (SIGTRAP) yet I am unable to step beyond or continue the debug session.

I've confirmed the same behviour with command line debuggerse as well as with VScode (both gdb and llvm)

[GitMensch]

From https://news.ycombinator.com/item?id=39172450:

The reason is because the ARM brk #0x1 instruction doesn't set the exception return address to the next instruction, so the debugger will just return to the breakpoint when it tries to resume, instead of running the next instruction. Recent versions of LLDB will recognize brk #0xf000 and automatically step over it when returning, but I don't think GDB does this. With GDB you would have to run something manually like jump *($pc + 4) to resume at the next instruction. Clang's __builtin_debugtrap() will generate brk #0xf000 automatically.

There is an open PR which does an inline version of raise (SIGTRAP) on arm/linux to counter that - you may want to test #28.

... and of course there is that note in the README:

Known Problem: if continuing execution after a debugbreak breakpoint hit doesn't work (e.g. on ARM or POWER), see HOW-TO-USE-DEBUGBREAK-GDB-PY.md for a workaround.