13

In my homegrown assert macro, I've been using asm("trap") on iOS devices (or asm("int3") on iOS simulators) to break in the debugger. However, in 64-bit builds for devices, I get an "unrecognized instruction mnemonic" for the trap instruction. Is there an equivalent for arm64?

(Alternatives like __builtin_trap() or raise(SIGINT) do work, but have some behavior I don't like; the former won't let you continue past the break, and the latter is a function so you're always one step below where you need to be in the stack when you break.)

leremjs
  • 973
  • 1
  • 9
  • 25

2 Answers2

8

I was able to break into the debugger (and continue afterwards) with asm("svc 0");. I’m not sure this is the correct way but it seems to do the job.

0xced
  • 25,219
  • 10
  • 103
  • 255
  • 3
    It's not correct. It calls unknown syscall and this raises [SIGSYS signal](https://en.wikipedia.org/wiki/Unix_signal#SIGSYS) (Bad system call) and debugger catches it. I think it's better to [send SIGSTOP](https://stackoverflow.com/a/44142833/468725) instead – Pavel P May 24 '17 at 01:52
0

Haven't tried iOS, but on Linux, the brk instruction causes SIGTRAP to be raised, which traps to the debugger if one is running.

asm("brk #0");
Nate Eldredge
  • 48,811
  • 6
  • 54
  • 82
  • This would be architecture-specific, right? So unless you're running Linux on arm64, I don't think it would apply to iOS. – leremjs Aug 30 '21 at 18:08
  • Well, the instruction generates a Breakpoint Instruction exception - that part is defined by the arm64 architecture and is OS-independent. Linux handles the exception by raising SIGTRAP. I am guessing that iOS would handle it by invoking whatever debugger facility might be available. I don't know the details of that, but it's what I would suggest trying. Of course, feedback from someone who tries it would be useful; if it actually doesn't work I'll delete the answer. – Nate Eldredge Aug 30 '21 at 19:30