Виртуализация исполнения машинного кода процессорной архитектуры ARM в Android-x86 окружении (1187396), страница 8
Текст из файла (страница 8)
Первым из них является невозможность исполнение кода изпроизвольного места в памяти. Поэтому было принято решение использоватьотдельный модуль выделения страниц памяти, для которых возможноразмещение и исполнение кода. Заметим, что в данном случае выделение52памяти происходило не с помощью платформо-независимых вызовов malloc(или схожих с ним), а посредством системного вызова mmap с надлежащимобразом выставленными флагами. Из-за того, что подобный механизм можетвыделять память исключительно страницами — изредка в транслируемыйкод требуется добавлять инструкции перехода между подобными страницамиисполняемого кода. В целях минимизации подобного поведения память подисполняемый код выделяется так называемыми “большими страницами”,объемом 2 мегабайта вместо стандартных 4-х килобайт.
За счет этогоинструкция перехода между страницами исполняемого кода встречаетсянастолько редко, что фактически не влияет на производительность.В процессе своей работы транслятор машинного кода заполняетпроцессорными инструкциями описанную выше память. Для этого вструктуре, соответствующей блоку кода содержатся указатель на страницу скодом (stub_chunk_t* head_chunk), а также адреса начала и конца областипамяти с кодом, который соответствует данному блоку ARM кода (uint8_t*stub_addr; uint8_t *stub_tail_addr).Также данная структура данных включает в себя полную информациюо инструкциях ARM кода, а также о использовании ими регистров (даннаяинформация заполняется на этапе анализа использования регистров).Регистровый аллокатор в свою очередь для данной последовательностиинструкций распределяет нативные x86 регистры и сохраняет даннуюинформацию, передавая в транслятор. Таким образом мы получаем списокописаний инструкций данного блока кода (trans_insn_t *insn_list_head;trans_insn_t *insn_list_tail), а также в случае, если блок кода заканчиваетсяинструкцией ветвления — ее описатель отдельно (trans_insn_t *branch_insn).Двамассиваномероврегистровпредставляютсобойкартысоответствия регистрами ARM — x86.
Данная информация уже известна53после стадии регистрового аллокатора, и далее используется в стадииоптимизации за счет связывания блоков, которая будет описана далее.Рассмотримв каком виде хранится информация о использованиирегистров, а также о соответствии между ARM регистрами и нативными x86регистрами. Для этих целей используется отдельная структура, содержащаяследующие поля:typedef struct trans_insn {addr_t addr;const struct instr_description *desc;size_t len;op_t op;uint16_t reg_usage_mask;union {arm_reg_t strict_reg_map[4];uint32_t strict_reg_map_uint;};struct trans_insn *prev;struct trans_insn *next;} trans_insn_t;Данная структура в первую очередь поддерживает двусвязный списокза счет двух указателей (struct trans_insn *prev; struct trans_insn *next). Кромеинформации о самой инструкции (ее адрес, длина, опкод) в данной структуретакжехранитсямаскаиспользованияARMрегистров(uint16_treg_usage_mask).Однако наиболее проблематичной для трансляции в данном случаеявляетсяиспользованиеstrict_reg_map[4]).Этофункциональностьвфиксированногонеобходимоархитектуреиз-заIA-3254отображениятого,чтоограничена(arm_reg_tопределеннаяопределеннымирегистрами.
К примеру результат умножения двух 32-битных чисел можетбыть полностью сохранен только в пару регистров EAX:EDX.Другой пример — это сдвиг регистра на нефиксированное количествобит, которое хранится в другом регистре в архитектуре x86 можетпроизводиться исключительно с помощью регистра ECX. В это же время всимметричной архитектуре ARM данные операции могут быть произведенынад любыми наборами регистров, что заставляет в некоторых случаяхдополнительно и заранее фиксировать отображение регистров.Получиввышеописаннуюинформациюалгоритмтрансляциипоследовательно для инструкций вызывает функции трансляции дляопределённых классов инструкций или их отдельных представителей,которые в свою очередь после анализа опкода оригинальной ARMинструкции генерируют исполняемый x86 код и записывают его всоответствующие страницы исполняемой памяти.
В данном случае подобныймеханизм схож с процедурой эмуляции, с той разницей, что вместонепосредственного исполнения инструкции генерируется машинный код,который выполняет эквивалентную процедуру, используя при этомуописанный выше механизм отображения регистров.В качестве примера рассмотрим одну из функций трансляции — ARMинструкции складывания регистров, при этом регистр источника может бытьпобитово сдвинут.trans_status_ttrans_arm_add_reg(trans_insn_t*insn,reg_map[ARM_REG_COUNT], uint8_t **write_ptr){arm_reg_t rd, rn, rm;ARM_DECODE_ARGS_DNMS(insn->op, rd, rn, rm, bit_s);if (rd == REGPC && bit_s)55x86_reg_treturn TRANS_UNPREDICTABLE;uint8_t shift_type = (insn->op >> 5) & 0b11;uint8_t shift = (insn->op >> 7) & 0b11111;MOV_REG_REG(write_ptr, REG_TMP, reg_map[rm]);BARREL_SHIFTER_IMM_SHIFT(write_ptr, shift_type, REG_TMP, shift);if (rn == REGPC)ADD_REG_IMM32(write_ptr, REG_TMP, insn->addr + 8);elseADD_REG_REG(write_ptr, REG_TMP, reg_map[rn]);if (rd == REGPC)MOVD_MEM_REG_DISP8(write_ptr,REG_EBP, REG_TMP,ARM_REG_ADDR_DISP8(REGPC));elseMOV_REG_REG(write_ptr, reg_map[rd], REG_TMP);return TRANS_SUCCESS;}На выходе после этапа трансляции получаем набор полностьютранслированныхблоковкода,которыеполностьюповторяютфункциональность соответствующих блоков ARM кода.
Заметим, что за счетполного покрытия набора инструкций отпадает необходимость выхода вэмуляторпривстреченекоторыхинструкций.Первоначальноэтотребовалось для исполнения отдельного класса инструкций с нетривиальнойимплементацией, а также атомарных инструкций, но сейчас, как уже былосказано, — набор инструкций ARM полностью покрыт.7.5 Модуль связывания блоковКак уже было сказано ранее, в первоначальной версии реализациидинамической трансляции применялся подход, когда точка исполнениянативного кода возвращалась в эмулятор как только она достигала концанепрерывного блока ARM кода.Очевидно, что в таком случае много времени теряется во первых во56время собственно переключения контекста (с реального на виртуальный), чтовключает в себя активную работу со стеком и обращения к памяти, в которомнаходится VCPU — виртуальный контекст процессора.Также, так как инструкции переходов между блоков не исполнялисьнативно,аэмулировалисьпроизводительности,которые—небылипозволялидополнительныедостичьпотеримаксимальнойпроизводительности, которую может предоставить подход с полнойдинамической трансляцией.
Однако, с другой стороны, подход с разбиениеммашинного кода ARM на непрерывные блоки давал такие неоспоримыепреимущества, как возможность декомпозировать задачу трансляции нагораздо более мелкие и, что самое главное, независимые задачи с однойстороны, а с другой — позволял всецело положиться на подход анализаиспользования регистров, описанный выше.Заметим, что в случае трансляции всего бинарного файла с машиннымкодом нам потребовалось бы применить гораздо более сложный алгоритм,так как code-flow в произвольном месте ARM кода пришлось бы вычислятьне заранее, а динамически.Таким образом, обосновав необходимость каким-то образом избавитьсяот выходов в эмулятор на границе блоков было принято решениеиспользовать процедуру связывания блоков посредством инструкцийветвления из набора машинных инструкций процессорной архитектуры x86.Причем в каждом конкретном случае применялись инструкции, максимальноблизкие (а порой и эквивалентные) тем, которые встречались в конце блоковкода.
Однако в данном случае нас подстерегала проблема, котораязаключалась в архитектурном несоответствии флагов, которые влияли наповедение инструкций условного перехода. Рассмотрим подробнее флагиусловного исполнения для обеих архитектур.57В случае ARM за данную функциональность отвечают четыре бита врегистре CPSR (N, Z, C и V соответственно):1. Negative – результат операции получился отрицательным,2.
Zero – результат равен нулю,3. Carry – при выполнении операции с беззнаковыми числами произошелперенос,4. oVerflow – при выполнении операции со знаковыми числамипроизошло переполнение, результат не помещается в регистр.Как уже было сказано выше — каждый опкод в процессорнойархитектуре ARM имеет так называемую маску условного исполнения. Напрактике это означает, что от первых четырёх бит опкода зависит, будет липроцессор исполнять очередную инструкцию, и при какой комбинациизначений, находящихся в битах условного исполнения. Ниже представленатаблица корректных значений битов, находящихся в маске условногоисполненияопкода,атакжеописанияусловий,прикоторыхрассматриваемый опкод выполнится.CodeSuffixDescriptionFlags0000EQEqual / equals zeroZ0001NENot equal!Z0010CS / HSCarry set / unsigned higher or sameC0011CC / LOCarry clear / unsigned lower!C0100MIMinus / negativeN0101PLPlus / positive or zero!N580110VSOverflowV0111VCNo overflow!V1000HIUnsigned higherC and !Z1001LSUnsigned lower or same!C or Z1010GESigned greater than or equalN == V1011LTSigned less thanN != V1100GTSigned greater than!Z and (N == V)1101LESigned less than or equalZ or (N != V)1110ALAlways (default)anyВ то же самое время в случае процессорной архитектуры x86 делаобстоят несколько иначе.
За поведение условных инструкций отвечаетспециальный регистр EFLAGS, который помимо значений, которые в данномслучае не имеют значения содержит также четые бита флагов.Флагисостоянияотражаютрезультатвыполненияарифметическихинструкций, таких как ADD, SUB,MUL,DIV.● CF — устанавливается при переносе из/заёме в (при вычитании)старшийзначащийбитрезультатаипоказываетналичиепереполнения в беззнаковой целочисленной арифметике. Такжеиспользуется в длинной арифметике.● ZF — устанавливается, если результат машинной операции помодулю 2 в степени k (где k - разрядность ячейки) равен нулю.59● SF — равен значению старшего значащего бита результата, которыйявляется знаковым битом в знаковой арифметике.● OF — устанавливается, если целочисленный результат слишкомдлинный для размещения в целевом операнде (регистре или ячейкепамяти). Этот флаг показывает наличие переполнения в знаковойцелочисленной арифметике (в дополнительном коде).В длинной целочисленной арифметике флаг CF используетсясовместно с инструкциями сложения с переносом (ADC) и вычитания сзаёмом (SBB) для распространения переноса или заёма из одноговычисляемого разряда длинного числа в другой.Инструкции условного перехода Jcc (переход по условию cc —например, JNZ для перехода, если результат не ноль), SETcc (установитьзначениебайта-результатавзависимости от условия cc), LOOPcc(организация цикла) и CMOVcc (условное копирование) используют одинили несколько флагов состояния для проверки условия.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
