“svc #128” breaking in to debugger unexpectedly - how to debug?

Question

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?

Answer 1

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, eg 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