[lldb-dev] Stepping into function generates EXC_BAD_INSTRUCTION signal
Greg Clayton
gclayton at apple.com
Tue Dec 2 13:53:27 PST 2014
As I read the whole post I realized this probably isn't your issue. But please do make sure that your symbols are marked correctly.
> On Dec 2, 2014, at 1:46 PM, Greg Clayton <gclayton at apple.com> wrote:
>
> Your functions in the symbol table must be correctly marked as "thumb" functions and they probably aren't.
>
> To mark a function as thumb, you must set the "n_desc" field of all thumb functions to be "0x0008".
>
> Looking at a dump from "dsymutil -s" on a Master Detail template app built for armv7:
>
>
> % dsymutil -s Carp.app/Carp
> ----------------------------------------------------------------------
> Symbol table for: 'Carp.app/Carp' (armv7)
> ----------------------------------------------------------------------
> Index n_strx n_type n_sect n_desc n_value
> ======== -------- ------------------ ------ ------ ----------------
> .....
> [ 105] 00000611 0e ( SECT ) 01 0008 000000000000a108 '+[SKScene(Unarchive) unarchiveFromFile:]'
> [ 106] 0000063a 0e ( SECT ) 01 0008 000000000000a270 '-[GameViewController viewDidLoad]'
> [ 107] 0000065c 0e ( SECT ) 01 0008 000000000000a404 '-[GameViewController shouldAutorotate]'
> [ 108] 00000683 0e ( SECT ) 01 0008 000000000000a414 '-[GameViewController supportedInterfaceOrientations]'
> [ 109] 000006b8 0e ( SECT ) 01 0008 000000000000a494 '-[GameViewController didReceiveMemoryWarning]'
> [ 110] 000006e6 0e ( SECT ) 01 0008 000000000000a4d8 '-[GameViewController prefersStatusBarHidden]'
> [ 111] 00000713 0e ( SECT ) 01 0008 000000000000a4e8 '-[AppDelegate application:didFinishLaunchingWithOptions:]'
> [ 112] 0000074d 0e ( SECT ) 01 0008 000000000000a530 '-[AppDelegate applicationWillResignActive:]'
> [ 113] 00000779 0e ( SECT ) 01 0008 000000000000a558 '-[AppDelegate applicationDidEnterBackground:]'
> [ 114] 000007a7 0e ( SECT ) 01 0008 000000000000a580 '-[AppDelegate applicationWillEnterForeground:]'
> [ 115] 000007d6 0e ( SECT ) 01 0008 000000000000a5a8 '-[AppDelegate applicationDidBecomeActive:]'
> [ 116] 00000801 0e ( SECT ) 01 0008 000000000000a5d0 '-[AppDelegate applicationWillTerminate:]'
> [ 117] 0000082a 0e ( SECT ) 01 0008 000000000000a5f8 '-[AppDelegate window]'
> [ 118] 00000840 0e ( SECT ) 01 0008 000000000000a614 '-[AppDelegate setWindow:]'
> [ 119] 0000085a 0e ( SECT ) 01 0008 000000000000a640 '-[AppDelegate .cxx_destruct]'
> [ 120] 00000877 0e ( SECT ) 01 0008 000000000000a668 '-[GameScene didMoveToView:]'
> [ 121] 00000893 0e ( SECT ) 01 0008 000000000000a830 '_CGPointMake'
> [ 122] 000008a0 0e ( SECT ) 01 0008 000000000000a868 '-[GameScene touchesBegan:withEvent:]'
> [ 123] 000008c5 0e ( SECT ) 01 0008 000000000000ab84 '-[GameScene update:]'
> [ 124] 000008da 1e (PEXT SECT ) 01 0008 000000000000ac4c '_objc_autoreleaseReturnValue$shim'
>
>
> Note all of these symbol table entries have "n_desc" set to 0x0008 to indicate they are thumb functions.
>
> Greg Clayton
>
>> On Nov 26, 2014, at 8:26 AM, Mario Zechner <badlogicgames at gmail.com> wrote:
>>
>> Hi,
>>
>> we generate thumbv7 binaries for iOS devices. We deploy, launch and debug those via LLDB. Stepping into functions seems to almost always generate a EXC_BAD_INSTRUCTION signal. The signal is not generated when running the app without the debugger attached. It is also not generated when we attach a debugger, but simply let the app run without breakpoints or any stepping.
>>
>> Here's one of these function's LLVM IR:
>>
>> =======================
>> define external void @"[J]java.lang.Object.<init>()V"(%Env* %p0, %Object* %p1) nounwind noinline optsize {
>> label0:
>> call void @"llvm.dbg.declare"(metadata !{%Env* %p0}, metadata !19), !dbg !{i32 136, i32 0, metadata !{i32 786478, metadata !0, metadata !1, metadata !"[J]java.lang.Object.<init>()V", metadata !"[J]java.lang.Object.<init>()V", metadata !"", i32 136, metadata !15, i1 false, i1 true, i32 0, i32 0, null, i32 256, i1 false, void (%Env*, %Object*)* @"[J]java.lang.Object.<init>()V", null, null, metadata !17, i32 136}, null}
>> %r0 = alloca %Object*
>> store %Object* null, %Object** %r0
>> call void @"llvm.dbg.declare"(metadata !{%Object** %r0}, metadata !21), !dbg !{i32 136, i32 0, metadata !14, null}
>> store %Object* %p1, %Object** %r0
>> call void @"register_finalizable"(%Env* %p0, %Object* %p1), !dbg !{i32 136, i32 0, metadata !18, null}
>> ret void, !dbg !{i32 136, i32 0, metadata !18, null}
>> }
>> =======================
>>
>> The corresponding thumbv7 assembler code as generated by LLVM:
>>
>> =======================
>> .globl "_[J]java.lang.Object.<init>()V"
>> .align 2
>> .code 16 @ @"[J]java.lang.Object.<init>()V"
>> .thumb_func "_[J]java.lang.Object.<init>()V"
>> "_[J]java.lang.Object.<init>()V":
>> .cfi_startproc
>> Lfunc_begin18:
>> .loc 1 136 0 @ Object.java:136:0
>> @ BB#0: @ %label0
>> .loc 1 136 0 @ Object.java:136:0
>> push {r7, lr}
>> mov r7, sp
>> sub sp, #4
>> @DEBUG_VALUE: [J]java.lang.Object.<init>()V:__$env <- R0
>> movs r2, #0
>> str r2, [sp]
>> str r1, [sp]
>> .loc 1 136 0 prologue_end @ Object.java:136:0
>> Ltmp6:
>> ldr r2, [r1]
>> ldr r2, [r2, #48]
>> tst.w r2, #1048576
>> Ltmp7:
>> @DEBUG_VALUE: [J]java.lang.Object.<init>()V:__$env <- R0
>> it ne
>> blxne __bcRegisterFinalizer
>> add sp, #4
>> pop {r7, pc}
>> Ltmp8:
>> Lfunc_end18:
>> "L_[J]java.lang.Object.<init>()V_end":
>>
>> .cfi_endproc
>> =======================
>>
>> Now, when stepping into this function, LLDB receives a signal from the debug server:
>>
>> =======================
>> (lldb) s
>> Process 176 stopped
>> * thread #1: tid = 0x11f5, 0x0023e2ec AttachTestIOSDev`[J]java.lang.Object.<init>(__$env=0x0169efc8, __$this=0x0174cd10)V + 24 at Object.java:136, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_ARM_UNDEFINED, subcode=0xffd1b001)
>> frame #0: 0x0023e2ec AttachTestIOSDev`[J]java.lang.Object.<init>(__$env=0x0169efc8, __$this=0x0174cd10)V + 24 at Object.java:136
>> =======================
>>
>> Disassembling around the PC gives:
>>
>> =======================
>> (lldb) disassemble --pc
>> AttachTestIOSDev`[J]java.lang.Object.<init>()V + 24 at Object.java:136:
>> -> 0x23e2ec: .long 0xb001ffd1 ; unknown opcode
>> 0x23e2f0: pop {r7, pc}
>>
>> AttachTestIOSDev`[J]java.lang.Object.<init>()V + 30:
>> 0x23e2f2: nop
>>
>> Disassembling until the beginning of the frame gives:
>>
>> (lldb) disassemble -f
>> AttachTestIOSDev`[J]java.lang.Object.<init>()V at Object.java:136:
>> 0x23e2d4: push {r7, lr}
>> 0x23e2d6: mov r7, sp
>> 0x23e2d8: sub sp, #0x4
>> 0x23e2da: movs r2, #0x0
>> 0x23e2dc: str r2, [sp]
>> 0x23e2de: str r1, [sp]
>> 0x23e2e0: ldr r2, [r1]
>> 0x23e2e2: ldr r2, [r2, #0x30]
>> 0x23e2e4: tst.w r2, #0x100000
>> 0x23e2e8: it ne
>> 0x23e2ea: blne 0x429290 ; _bcRegisterFinalizer
>> 0x23e2ee: add sp, #0x4
>> 0x23e2f0: pop {r7, pc}
>>
>> Accprding to this, execution should never end up at address 0x23e2ec. That's right in the middle of the blne and add instructions in the second disassembly. I have a hunch that the debugserver on the device may interfere here, e.g. add a trap instruction to implement the stepping. I'm not quite sure what to make of it.
>>
>> I'd appreciate any hints. If you require more information, i got plenty of logs :)
>>
>> Thanks,
>> Mario
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
More information about the lldb-dev
mailing list