Пытаясь понять ARM сборки IOS приложение

Question

рассмотрим следующую цель C определение интерфейса

#import <Foundation/Foundation.h> 

@interface MyClass : NSObject 

    @property NSObject* myprop; 

@end 

Узел Генерация ARMv7 на Xcode 5 для [MyClass myprop] выглядит

.code 16      @ @"\01-[MyClass myprop]" 
    .thumb_func "-[MyClass myprop]" 
"-[MyClass myprop]": 
Lfunc_begin0: 
    .cfi_startproc 
@ BB#0: 
    sub sp, #8 
    @DEBUG_VALUE: -[MyClass myprop]:self <- undef 
    @DEBUG_VALUE: -[MyClass myprop]:_cmd <- undef 
    str r0, [sp, #4] 
    str r1, [sp] 
    ldr r0, [sp, #4] 
    movw r2, :lower16:(_OBJC_IVAR_$_MyClass.myprop-(LPC0_0+4)) 
    movt r2, :upper16:(_OBJC_IVAR_$_MyClass.myprop-(LPC0_0+4)) 
LPC0_0: 
    add r2, pc 
    ldr r2, [r2] 
    movs r3, #1 
    add sp, #8 
    b.w _objc_getProperty 
Ltmp0: 
Lfunc_end0: 
    .cfi_endproc 

Я хочу, чтобы понять, в результате сборка и задать следующие вопросы:

1) Последняя инструкция (b.w _objc_getProperty) устанавливает ПК по адресу ярлык _objc_getProperty. Но как эта процедура знает, куда вернуться? Предполагает ли он, что метод вызывается с помощью bl, и поэтому в реестре ссылок указан адрес назначения?

2) Что делают 3 линии ниже второго @DEBUG_VALUE?

Если я правильно понимаю, содержимое r0 хранится при смещении стека 4, r1 хранится в текущем стеке (смещение 0), а r0 заполняется смещением стека 4. Но почему последняя инструкция меняет что-либо ? Разве это не означает, что r0 заполнено тем, что оно уже содержит? Для каких значений используются значения? _obj_getProperty?

3) Почему r3 установлен в 1 в конце? (movs r3, #1)?

Answer 1

В коде C функция, вероятно, выглядеть следующим образом:

resulttype Lfunc_begin0(type1 arg1, type2 arg2) 
{ 
    return _objc_getProperty(arg1, arg2, Myclass_myprop, 1); 
} 

Сначала давайте рассмотрим следующий пример:

int func(void) 
{ 
    a(); 
    b(); 
    return c(); 
} 

Теперь можно было бы сделать вызов функции «с() "следующим образом:

save_lr 
bl a 
bl b 
bl c 
restore_original_lr 
bx lr 

В качестве альтернативы можно будет выполнить следующее ИНГ код:

save_lr 
bl a 
bl b 
restore_original_lr 
b c 

В этом случае «Ьх Л.Р.» инструкция в конце «с()» будет перейти непосредственно к функции, которая называется OURSELF, и мы не должны делать «Ьх Л.Р.».

Поскольку некоторые вызовы функций в коде C могут уничтожить содержимое Rop и R, неоптимизированный код C сохранит эти регистры в стек только для случая, когда их значение потребуется позже. Хорошо оптимизированный код C проверяет это и удаляет три команды после строк «@DEBUG». Даже строки «добавить SP» и «sub SP» можно было бы оптимизировать!

Функция _obj_getProperty, очевидно, принимает четыре аргумента. R0 и R1 просто передаются (как показано в приведенном выше коде C), в то время как R2 и R3 являются дополнительными аргументами для этой функции.

Что действительно означает 4-й аргумент (R3 = 1), не видно из приведенного здесь кода ассемблера.