Wrong method implementation address from otool for armv7?

问题

I'm constantly getting 1 byte offset for implementation address of method shown by 'otool'.

For an example 'otool -o' gives 0xe99d5 but 'otool -tvV' gives:

+[NSError(SomeCategory) someMethod]:
000e99d4            b590        push    {r4, r7, lr}
000e99d6        f6441184        movw    r1, 0x4984
000e99da            af01        add     r7, sp, #4
000e99dc        f2c0010a        movt    r1, 0xa

So method starts at 0xe99d4. 0xe99d5 looks wrong, not aligned. I believe that 'otool' works fine and I don't understand some aspects of implementation. How to interpret the output ?

回答1:

Modern ARM cores has two types of instruction sets. Original one is called arm mode where each instruction is four bytes long and newer one is called thumb2 (as you can guess it has already passed some iterations) where instructions can be two or four bytes long (the reason for the introduction is code density).

CPU can change modes when it is making a branch and the way to notify CPU about instruction set used is by setting the least significant bit in address of the instruction to be jumped. If it is 0 instruction will be interpreted as arm mode, if it is 1 they will be interpreted as thumb mode.

So what you are seeing is your function is in thumb2 mode which we can verify by seeing it consist of two and four byte long instructions.

来源：https://stackoverflow.com/questions/15045144/wrong-method-implementation-address-from-otool-for-armv7