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 <badlogicga...@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@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
