0

There are a series of StackOverflow questions that mention unexpectedly breaking in to the debugger after a svc #128 instruction. In dealing with this issue myself, I'd like to ask some general questions about when and why this occurs.

  • In detail what svc #128 is used for in iOS?
  • What causes it to break in to the debugger?
  • Is there a way of suppressing breaking in to the debugger during development?
  • Possible methods to debug the underlying cause of this issue?
  • Successful fixes that people have used in the past?
brunobowden
  • 1,492
  • 19
  • 37
  • `SVC` ("Supervisor Call") is just the ARM system call instruction. [A quick poke around](http://theiphonewiki.com/wiki/Kernel_Syscalls) reveals that, like most modern things, iOS uses a register-based syscall convention, so the #128 is largely immaterial but other program state matters. I don't know iOS, but generally, breaking into the debugger unexpectedly means that if you hadn't had a debugger attached you would have just crashed - [this seems relevant](http://stackoverflow.com/q/2611607/3156750). With that in mind, "how (generally) can I debug dodgy code?" is clearly too broad a question. – Notlikethat Jan 04 '15 at 17:29
  • Thanks for the comment. Turns out that in this case, is that my code is working correctly. The issue is that LLDB by default breaks on certain thread to thread signals, e.g. SIGUSR2... once I set the debugger to ignore this and automatically continue execution, then it works fine. Looking as the assembler, the prior call was `movz x16, #328` which corresponds to pthread_kill in your useful link. – brunobowden Jan 04 '15 at 19:05

1 Answers1

2

The svc #128 or svc 0x80 call is the Supervisor Call within the ARM instruction set (ARM Documentation). You need to look at the register value to indicate what's being called.

Example assembler:

libsystem_kernel.dylib`__pthread_kill:
0x195557268:  movz   x16, #328                 // NOTE THIS VALUE
0x19555726c:  svc    #128
0x195557270:  b.cc   0x195557288               ; __pthread_kill + 32
...

Lookup the movz value (in this case #328) in this table of Kernel System Calls. For #328, this corresponds to pthread_kill, which matches the name of the method listed above. When the interrupt is called, it will land on the instruction immediately after svc, in this example the b.cc instruction.

Note that LLDB also breaks for certain thread to thread signals, e.g. SIGUSR2, even if it's intentional and correct. You can configure Xcode to ignore this and continue execution without an issue:

Permanently configuring LLDB (in Xcode 4.3.2) not to stop on signals

Thanks to Notlikethat for their input

Community
  • 1
  • 1
brunobowden
  • 1,492
  • 19
  • 37