Related
How do I modify #0x1 to #0x0 of the and instruction in any of the dissassembler?
00000001005c3fc0 and w0, w8, #0x1
00000001005c3fc4 ldp x29, x30, [sp, #0x10]
00000001005c3fc8 ldp x20, x19, [sp], #0x20
00000001005c3fcc ret
The results should return #0x0 instead of #0x1
I have tried using hopper, but it seems to me I can only change the instruction and to something else by referring to the last bit.
It appears that the usual approach to calling printf from aarch64 asm code that works just fine on Linux does not work on MacOS running on the Apple M1.
Is there any documentation that explains what has changed?
I find that the parameters that I put in x0..x2 are getting garbled in the printf output.
The Darwin arm64 ABI passes all varags arguments on the stack, each padded to the next multiple of 8 bytes. (Types that don't fit into 8 bytes have a pointer passed instead. Regular arguments that don't fit into x0-x7/q0-q7 come before varargs on the stack, naturally aligned.)
Here's a simple example:
.globl _main
.align 2
_main:
stp x29, x30, [sp, -0x10]!
sub sp, sp, 0x10
mov x8, 66
str x8, [sp]
adr x0, Lstr
bl _printf
mov w0, 0
add sp, sp, 0x10
ldp x29, x30, [sp], 0x10
ret
Lstr:
.asciz "test: %x\n"
Note that this is different from non-varargs arguments to unprototyped functions that are passed on the stack, which are only padded up to 4 bytes (sizeof(int)). The following code:
#include <stdio.h>
#include <stdint.h>
extern void func();
__asm__
(
"_func:\n"
" ret\n"
);
int main(void)
{
uint8_t a = 1,
b = 2,
c = 3;
printf("%hhx %hhx %hhx %hhx %hhx %hhx\n", a, b, c, a, b, c);
func(a, b, c, a, b, c, a, b, c, a, b, c);
return 0;
}
compiles down to this with -O2:
;-- _main:
0x100003ee8 ff0301d1 sub sp, sp, 0x40
0x100003eec fd7b03a9 stp x29, x30, [sp, 0x30]
0x100003ef0 fdc30091 add x29, sp, 0x30
0x100003ef4 68008052 mov w8, 3
0x100003ef8 49008052 mov w9, 2
0x100003efc e92302a9 stp x9, x8, [sp, 0x20]
0x100003f00 2a008052 mov w10, 1
0x100003f04 e82b01a9 stp x8, x10, [sp, 0x10]
0x100003f08 ea2700a9 stp x10, x9, [sp]
0x100003f0c 20040010 adr x0, str._hhx__hhx__hhx__hhx__hhx__hhx_n
0x100003f10 1f2003d5 nop
0x100003f14 13000094 bl sym.imp.printf
0x100003f18 480080d2 mov x8, 2
0x100003f1c 6800c0f2 movk x8, 3, lsl 32
0x100003f20 690080d2 mov x9, 3
0x100003f24 2900c0f2 movk x9, 1, lsl 32
0x100003f28 e92300a9 stp x9, x8, [sp]
0x100003f2c 20008052 mov w0, 1
0x100003f30 41008052 mov w1, 2
0x100003f34 62008052 mov w2, 3
0x100003f38 23008052 mov w3, 1
0x100003f3c 44008052 mov w4, 2
0x100003f40 65008052 mov w5, 3
0x100003f44 26008052 mov w6, 1
0x100003f48 47008052 mov w7, 2
0x100003f4c e6ffff97 bl sym._func
0x100003f50 00008052 mov w0, 0
0x100003f54 fd7b43a9 ldp x29, x30, [sp, 0x30]
0x100003f58 ff030191 add sp, sp, 0x40
0x100003f5c c0035fd6 ret
Giving the function an actual prototype allows the removal of any padding (except the one that serves alignment purposes), like so (note the last argument being 8 bytes):
extern void func(uint8_t, uint8_t, uint8_t, uint8_t, uint8_t, uint8_t,
uint8_t, uint8_t, uint8_t, uint8_t, uint8_t, uint64_t);
The code then compiles down to:
;-- _main:
0x100003ee4 ff4301d1 sub sp, sp, 0x50
0x100003ee8 f44f03a9 stp x20, x19, [sp, 0x30]
0x100003eec fd7b04a9 stp x29, x30, [sp, 0x40]
0x100003ef0 fd030191 add x29, sp, 0x40
0x100003ef4 73008052 mov w19, 3
0x100003ef8 54008052 mov w20, 2
0x100003efc f44f02a9 stp x20, x19, [sp, 0x20]
0x100003f00 28008052 mov w8, 1
0x100003f04 f32301a9 stp x19, x8, [sp, 0x10]
0x100003f08 e85300a9 stp x8, x20, [sp]
0x100003f0c 20040010 adr x0, str._hhx__hhx__hhx__hhx__hhx__hhx_n
0x100003f10 1f2003d5 nop
0x100003f14 13000094 bl sym.imp.printf
0x100003f18 68208052 mov w8, 0x103
0x100003f1c f30700f9 str x19, [sp, 8]
0x100003f20 f40b0039 strb w20, [sp, 2]
0x100003f24 e8030079 strh w8, [sp]
0x100003f28 20008052 mov w0, 1
0x100003f2c 41008052 mov w1, 2
0x100003f30 62008052 mov w2, 3
0x100003f34 23008052 mov w3, 1
0x100003f38 44008052 mov w4, 2
0x100003f3c 65008052 mov w5, 3
0x100003f40 26008052 mov w6, 1
0x100003f44 47008052 mov w7, 2
0x100003f48 e6ffff97 bl sym._func
0x100003f4c 00008052 mov w0, 0
0x100003f50 fd7b44a9 ldp x29, x30, [sp, 0x40]
0x100003f54 f44f43a9 ldp x20, x19, [sp, 0x30]
0x100003f58 ff430191 add sp, sp, 0x50
0x100003f5c c0035fd6 ret
I am trying to get the the address of a label in thumb assembly and I am having some trouble.
I already read this post but that cannot help me and I will explain why.
I am writing an simple program with Thumb assembly ( unfortunately I cannot use Thumb2 ).
Let's consider this code:
.arch armv5te
.syntax unified
.text
.thumb
.thumb_func
thumbnow:
0x0 PUSH {LR}
0x2 LDR R0, =loadValues
0x4 POP {PC}
.align
loadValues:
0x8 .word 0xdeadbee1
0xC .word 0xdeadbee2
0x10 .word 0xdeadbee3
I am using the arm-linux-gnueabi toolchain to assemble that.
My microcontroller doesn't have an MMU so the memory address are static, no virtual pages etc.
The thing that I am trying to do is to make R0 having the value of 0x8 here so that then I can access the three words like this:
LDR R1, [R0]
LDR R2, [R0,#4]
LDR R3, [R0,#8]
This is not possible with LDR though because the value in the word is not possible to fit in a MOV command. The documentation of the assembler states that if the value cannot fit in a MOV command then it will put the value in a literal pool.
So my question is, is it possible in Thumb assembly to get the actual address of the label if the content of the address cannot fit in a MOV command?
Starting with this
.thumb
ldr r0,=hello
adr r0,hello
nop
nop
nop
nop
hello:
.word 0,1,2,3
gives this unlinked
00000000 <hello-0xc>:
0: 4806 ldr r0, [pc, #24] ; (1c <hello+0x10>)
2: a002 add r0, pc, #8 ; (adr r0, c <hello>)
4: 46c0 nop ; (mov r8, r8)
6: 46c0 nop ; (mov r8, r8)
8: 46c0 nop ; (mov r8, r8)
a: 46c0 nop ; (mov r8, r8)
0000000c <hello>:
c: 00000000 andeq r0, r0, r0
10: 00000001 andeq r0, r0, r1
14: 00000002 andeq r0, r0, r2
18: 00000003 andeq r0, r0, r3
1c: 0000000c andeq r0, r0, r12
linked
00001000 <hello-0xc>:
1000: 4806 ldr r0, [pc, #24] ; (101c <hello+0x10>)
1002: a002 add r0, pc, #8 ; (adr r0, 100c <hello>)
1004: 46c0 nop ; (mov r8, r8)
1006: 46c0 nop ; (mov r8, r8)
1008: 46c0 nop ; (mov r8, r8)
100a: 46c0 nop ; (mov r8, r8)
0000100c <hello>:
100c: 00000000 andeq r0, r0, r0
1010: 00000001 andeq r0, r0, r1
1014: 00000002 andeq r0, r0, r2
1018: 00000003 andeq r0, r0, r3
101c: 0000100c andeq r1, r0, r12
both ways r0 will return the address to the start of data from which you can then offset into that data from the caller or wherever.
Edit
.thumb
adr r0,hello
nop
nop
nop
arm-none-eabi-as so.s -o so.o
so.s: Assembler messages:
so.s:2: Error: address calculation needs a strongly defined nearby symbol
So the tool won't turn that into a load from the pool for you.
For what you want to do I think the pc relative add (adr) is the best you are going to get. You can try other toolchains as all of this is language and toolchain specific (assembly language is defined by the assembler not the target and for each toolchain (with an assembler) there can be differences in the language). Over time within gnu, how the linker and assembler worked together has changed, the linker patches up things it didn't used to.
You could of course go into the linker and add code to it to perform this optimization, the problem is most likely that by link time the linker is looking to resolve an address in the pool which is easy for it to do it doesn't have to change the instruction, the assembler would have to leave information for the linker that this is not just a fill this memory location with an address thing, either you modify gas to allow adr to work, and then if the linker cant resolve it within the instruction then the linker bails out with an error.'
Or you could just hard-code what you want and maintain it. I am not sure why the adr solution isn't adequate.
mov r0,#8 is a valid thumb instruction.
I'm writing THUMB code for an embedded core (ARM7TDMI) that needs to be linked to existing THUMB code. I'm using the GNU ARM embedded toolchain (link). I cannot get the linker to treat the existing external code as THUMB; it seems to always think that it's ARM. The existing code that I'm linking to is absolutely static and cannot be changed/recompiled (it's a plain binary sitting on a ROM chip, basically).
Here is an example program, multiply.c, that demonstrates the issue:
extern int externalFunction(int x);
int multiply(int x, int y)
{
return externalFunction(x * y);
}
Compiled using:
arm-none-eabi-gcc -o multiply.o -c -O3 multiply.c -march=armv4t -mtune=arm7tdmi -mthumb
arm-none-eabi-ld -o linked.o multiply.o -T symbols.txt
Where symbols.txt is a simple linker script:
SECTIONS
{
.text 0x8000000 : { *(.text) }
}
externalFunction = 0x8002000;
When I objdump -d linked.o, I get:
08000000 <multiply>:
8000000: b510 push {r4, lr}
8000002: 4348 muls r0, r1
8000004: f000 f804 bl 8000010 <__externalFunction_from_thumb>
8000008: bc10 pop {r4}
800000a: bc02 pop {r1}
800000c: 4708 bx r1
800000e: 46c0 nop ; (mov r8, r8)
08000010 <__externalFunction_from_thumb>:
8000010: 4778 bx pc
8000012: 46c0 nop ; (mov r8, r8)
8000014: ea0007f9 b 8002000 <externalFunction>
Instead of branching directly to 0x8002000, it branches to a stub that switches to ARM mode first and then branches to 0x8002000 in ARM mode. I want that BL to branch directly to 0x8002000 and stay in THUMB mode, so that I'd get this instead:
08000000 <multiply>:
8000000: b510 push {r4, lr}
8000002: 4348 muls r0, r1
8000004: ???? ???? bl 8002000 <__externalFunction>
8000008: bc10 pop {r4}
800000a: bc02 pop {r1}
800000c: 4708 bx r1
ABI and calling convention issues aside, how do I achieve this?
one way to do it is make it do what you want
branchto.s
.thumb
.thumb_func
.globl branchto
branchto:
bx r0
so.c
extern unsigned int externalFunction;
extern int branchto ( unsigned int, int );
int fun ( int x )
{
return(branchto(externalFunction,x)+3);
}
so.ld
SECTIONS
{
.text 0x8000000 : { *(.text) }
}
externalFunction = 0x8002001;
producing
08000000 <fun>:
8000000: 4b04 ldr r3, [pc, #16] ; (8000014 <fun+0x14>)
8000002: b510 push {r4, lr}
8000004: 0001 movs r1, r0
8000006: 6818 ldr r0, [r3, #0]
8000008: f000 f806 bl 8000018 <branchto>
800000c: 3003 adds r0, #3
800000e: bc10 pop {r4}
8000010: bc02 pop {r1}
8000012: 4708 bx r1
8000014: 08002001 stmdaeq r0, {r0, sp}
08000018 <branchto>:
8000018: 4700 bx r0
Ross Ridge's solution in the comments works
static int (* const externalFunction)(int x) = (int (*)(int)) 0x80002001;
int fun ( int x )
{
return((* externalFunction)(x)+3);
}
but the hardcoded address is in the code not the linker script if that matters, was trying to solve that and couldnt.
08000000 <fun>:
8000000: b510 push {r4, lr}
8000002: 4b03 ldr r3, [pc, #12] ; (8000010 <fun+0x10>)
8000004: f000 f806 bl 8000014 <fun+0x14>
8000008: 3003 adds r0, #3
800000a: bc10 pop {r4}
800000c: bc02 pop {r1}
800000e: 4708 bx r1
8000010: 80002001 andhi r2, r0, r1
8000014: 4718 bx r3
8000016: 46c0 nop ; (mov r8, r8)
I prefer the assembly solution for something like this to force the exact instruction I want. Naturally if you had linked in the external function it would/should have just worked (there are some exceptions but gnu is getting really good at resolving the to and from arm/thumb for you in the linker).
I dont see it as a gnu bug actually, but instead they need a way in the linker script to declare that variable as a thumb function address rather than just some generic linker defined variable (likewise as an arm function address). Just like .thumb_func does (or a longer function/procedure declaration)
.word branchto
.thumb
.globl branchto
branchto:
bx r0
8000018: 0800001c stmdaeq r0, {r2, r3, r4}
0800001c <branchto>:
800001c: 4700 bx r0
.word branchto
.thumb
.thumb_func
.globl branchto
branchto:
bx r0
8000018: 0800001d stmdaeq r0, {r0, r2, r3, r4}
0800001c <branchto>:
800001c: 4700 bx r0
by just reading the gnu linker documentation there may be hope to get what you want
SECTIONS
{
.text0 0x08000000 : { so.o }
.text1 0x08002000 (NOLOAD) : { ex.o }
}
ex.o comming from a dummy function to make everyone happy
int externalFunction ( int x )
{
return(x);
}
08000000 <fun>:
8000000: b510 push {r4, lr}
8000002: f001 fffd bl 8002000 <externalFunction>
8000006: 3003 adds r0, #3
8000008: bc10 pop {r4}
800000a: bc02 pop {r1}
800000c: 4708 bx r1
and the NOLOAD keeps the dummy function out of the binary.
arm-none-eabi-objcopy so.elf -O srec --srec-forceS3 so.srec
S00A0000736F2E7372656338
S3150800000010B501F0FDFF033010BC02BC0847C0461E
S315080000104743433A2028474E552920362E322E305C
S31508000020004129000000616561626900011F000046
S3150800003000053454000602080109011204140115CA
S31008000040011703180119011A011E021E
S70500000000FA
note it wasnt perfect there was extra garbage that got pulled in, perhaps symbols
08000000 <fun>:
8000000: b510 push {r4, lr}
8000002: f001 fffd bl 8002000 <externalFunction>
8000006: 3003 adds r0, #3
8000008: bc10 pop {r4}
800000a: bc02 pop {r1}
800000c: 4708 bx r1
800000e: 46c0 nop ; (mov r8, r8)
8000010: 3a434347
8000014: 4e472820
8000018: 36202955
800001c: 302e322e
8000020: 00294100
8000024: 65610000
8000028: 00696261
800002c: 00001f01
8000030: 54340500
8000034: 08020600
8000038: 12010901
800003c: 15011404
8000040: 18031701
8000044: 1a011901
which you can see in the srec, but the 0x08002000 code is not there so your actual external function will get called.
I would go with just making the instruction you want or function pointers with an assignment if you dont want any asm.
The other comments/answers using long branches do work, but it would still be nice to have a direct BL call and avoid the unnecessary load.
I believe I've found a workaround here. Create a dummy file (let's call it ext.c) with:
__attribute__((naked)) int externalFunction(int x){}
Compile this file to ext.o (same way as you compile multiply.c). This generates a dummy object file with a correctly decorated function symbol for externalFunction, whose address gets overridden by the linker script, resulting in the desired BL instruction:
Disassembly of section .text:
08000000 <multiply>:
8000000: b510 push {r4, lr}
8000002: 4348 muls r0, r1
8000004: f001 fffc bl 8002000 <externalFunction>
8000008: bc10 pop {r4}
800000a: bc02 pop {r1}
800000c: 4708 bx r1
800000e: 46c0 nop ; (mov r8, r8)
When i try to call a java/soap web service from iOS (objective c) using AFNetworking, after many times I get this error: "EXC_BAD_ACCESS"
on 0x71d678: ldr r0, [r4, #0x68].
But I noticed that if on iPhone (particularly iphone 6 or in generally on iOS8) I disable WIFI the error disappeared
I post the assembly code
libdispatch.dylib`_dispatch_timers_run:
0x71d5f0: push {r4, r5, r6, r7, lr}
0x71d5f2: add r7, sp, #0xc
0x71d5f4: push.w {r8, r10, r11}
0x71d5f8: sub sp, #0x18
0x71d5fa: movs r6, #0x0
0x71d5fc: str r0, [sp]
0x71d5fe: movw r0, #0xa83e
0x71d602: movt r0, #0x1
0x71d606: add r0, pc
0x71d608: add.w r1, r0, r6, lsl #6
0x71d60c: ldr r0, [r1, #8]!
0x71d610: str r1, [sp, #0x14]
0x71d612: cmp r0, #0x0
0x71d614: beq.w 0x71d776 ; _dispatch_timers_run + 390
0x71d618: ubfx r4, r6, #0x2, #0x1
0x71d61c: ldr r5, [sp]
0x71d61e: cbz r5, 0x71d632 ; _dispatch_timers_run + 66
0x71d620: ldr.w r0, [r5, r4, lsl #3]
0x71d624: str r0, [sp, #0x10]
0x71d626: cbz r0, 0x71d632 ; _dispatch_timers_run + 66
0x71d628: add.w r0, r5, r4, lsl #3
0x71d62c: ldr r0, [r0, #0x4]
0x71d62e: str r0, [sp, #0xc]
0x71d630: b 0x71d664 ; _dispatch_timers_run + 116
0x71d632: cmp r4, #0x0
0x71d634: bne 0x71d63c ; _dispatch_timers_run + 76
0x71d636: bl 0x70df20 ; _dispatch_get_nanoseconds
0x71d63a: b 0x71d648 ; _dispatch_timers_run + 88
0x71d63c: cmp r4, #0x1
0x71d63e: str r0, [sp, #0x10]
0x71d640: str r0, [sp, #0xc]
0x71d642: bne 0x71d64c ; _dispatch_timers_run + 92
0x71d644: blx 0x72b380 ; symbol stub for: mach_absolute_time
0x71d648: str r0, [sp, #0x10]
0x71d64a: str r1, [sp, #0xc]
0x71d64c: cbz r5, 0x71d664 ; _dispatch_timers_run + 116
0x71d64e: ldr r0, [sp, #0x10]
0x71d650: ldr r1, [sp, #0xc]
0x71d652: str.w r0, [r5, r4, lsl #3]
0x71d656: add.w r0, r5, r4, lsl #3
0x71d65a: str r1, [r0, #0x4]
0x71d65c: b 0x71d664 ; _dispatch_timers_run + 116
0x71d65e: mov r0, r4
0x71d660: bl 0x71c5bc ; _dispatch_timers_update
0x71d664: ldr r0, [sp, #0x14]
0x71d666: ldr.w r10, [r0]
0x71d66a: cmp.w r10, #0x0
0x71d66e: beq.w 0x71d776 ; _dispatch_timers_run + 390
0x71d672: ldr.w r0, [r10, #8]
0x71d676: mvns r4, r0
0x71d678: ldr r0, [r4, #0x68]
0x71d67a: cmp r0, r6
0x71d67c: bne 0x71d65e ; _dispatch_timers_run + 110
0x71d67e: mov r8, r10
0x71d680: ldr r5, [r8, #24]!
0x71d684: ldr r2, [sp, #0x10]
0x71d686: ldr.w r11, [r8, #4]
0x71d68a: subs r0, r5, #0x1
0x71d68c: sbc r1, r11, #0x0
0x71d690: cmp r0, r2
0x71d692: mov.w r0, #0x0
0x71d696: it hs
0x71d698: movhs r0, #0x1
0x71d69a: ldr r2, [sp, #0xc]
0x71d69c: cmp r1, r2
0x71d69e: mov.w r1, #0x0
0x71d6a2: it hs
0x71d6a4: movhs r1, #0x1
0x71d6a6: it eq
0x71d6a8: moveq r1, r0
0x71d6aa: cmp r1, #0x0
0x71d6ac: bne 0x71d776 ; _dispatch_timers_run + 390
0x71d6ae: ldr r0, [r4, #0x1c]
0x71d6b0: cmp r0, #0x1
0x71d6b2: bhi 0x71d65e ; _dispatch_timers_run + 110
0x71d6b4: ldr r0, [r4, #0x70]
0x71d6b6: cmp r0, #0x0
0x71d6b8: bne 0x71d65e ; _dispatch_timers_run + 110
0x71d6ba: str r6, [sp, #0x4]
0x71d6bc: ldr.w r6, [r10, #48]
0x71d6c0: ldr.w r3, [r10, #52]
0x71d6c4: ldr r0, [sp, #0x10]
0x71d6c6: ldr r1, [sp, #0xc]
0x71d6c8: mov r2, r6
0x71d6ca: str r3, [sp, #0x8]
0x71d6cc: subs r0, r0, r5
0x71d6ce: sbc.w r1, r1, r11
0x71d6d2: blx 0x72b240 ; symbol stub for: __udivdi3
0x71d6d6: mov r9, r6
0x71d6d8: adds r6, r0, #0x1
0x71d6da: adc r12, r1, #0x0
0x71d6de: lsrs r1, r6, #0x1f
0x71d6e0: orr.w r1, r1, r12, lsl #1
0x71d6e4: movs r2, #0x0
0x71d6e6: mvn r3, #0x80000000
0x71d6ea: orr.w r1, r1, r12, lsr #31
0x71d6ee: cmp r1, #0x0
0x71d6f0: mov.w r1, #0x0
0x71d6f4: itt ne
0x71d6f6: movne.w r12, #0x0
0x71d6fa: mvnne r6, #0x80000000
0x71d6fe: cmp.w r9, #0xffffffff
0x71d702: it eq
0x71d704: moveq r1, #0x1
0x71d706: ldr r0, [sp, #0x8]
0x71d708: cmp r0, #0x0
0x71d70a: it lt
0x71d70c: movlt r2, #0x1
0x71d70e: cmp r0, r3
0x71d710: it eq
0x71d712: moveq r2, r1
0x71d714: mov r3, r0
0x71d716: cbnz r2, 0x71d73c ; _dispatch_timers_run + 332
0x71d718: umull r1, r2, r6, r9
0x71d71c: mla r2, r6, r3, r2
0x71d720: mla r0, r12, r9, r2
0x71d724: adds r2, r1, r5
0x71d726: adc.w r3, r0, r11
0x71d72a: strd r2, r3, [r8]
0x71d72e: ldrd r0, r1, [r10, #56]
0x71d732: adds r0, r0, r2
0x71d734: adcs r1, r3
0x71d736: strd r0, r1, [r10, #32]
0x71d73a: b 0x71d750 ; _dispatch_timers_run + 352
0x71d73c: mov.w r0, #0xffffffff
0x71d740: str.w r0, [r8]
0x71d744: str.w r0, [r8, #4]
0x71d748: str.w r0, [r8, #8]
0x71d74c: str.w r0, [r8, #12]
0x71d750: mov r0, r4
0x71d752: bl 0x71c5bc ; _dispatch_timers_update
0x71d756: ldr r0, [sp, #0x10]
0x71d758: ldr r1, [sp, #0xc]
0x71d75a: strd r0, r1, [r10, #40]
0x71d75e: ldrex r0, [r4, #0x70]
0x71d762: add r0, r6
0x71d764: strex r1, r0, [r4, #0x70]
0x71d768: cmp r1, #0x0
0x71d76a: bne 0x71d75e ; _dispatch_timers_run + 366
0x71d76c: mov r0, r4
0x71d76e: bl 0x715934 ; _dispatch_wakeup
0x71d772: ldr r6, [sp, #0x4]
0x71d774: b 0x71d664 ; _dispatch_timers_run + 116
0x71d776: adds r6, #0x1
0x71d778: cmp r6, #0x7
0x71d77a: bne.w 0x71d5fe ; _dispatch_timers_run + 14
0x71d77e: add sp, #0x18
0x71d780: pop.w {r8, r10, r11}
0x71d784: pop {r4, r5, r6, r7, pc}
0x71d786: nop
Can someone help me, please?
On iphone 4s it's ok (iOS 7)
Thank you in advance
Claudio