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
