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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
