ARM/Thumb interworking в сборке

Question

Я строю проект Windows Phone с некоторыми его частями в сборке. Мой файл сборки находится в режиме ARM (CODE32), и он пытается перейти к функции C, которую я знаю, скомпилирован для Thumb. Код выглядит следующим образом:

ldr r12, [pFunc] 
    mov pc, r12 
pFunc 
    dcd My_C_Function 

Вот что странно. Значение в pFunc в фрагменте является указателем на функцию thunk plus one. То есть устанавливается 0-й бит, как если бы целью перехода был Thumb, а команда перехода - BX. Но трюк явно ARM! Thunk загружает адрес тела функции плюс один и выполняет BX для него, правильно переключая режимы.

Попытка BX к этому адресу, вероятно, потерпит крах, поскольку это переключит режимы и попытается выполнить код ARM в режиме Thumb, это не очень хорошая идея. Пытаться просто перейти на этот адрес (как это делает текущий код), вероятно, тоже произойдет сбой, потому что ПК окажется неравнозначным.

Я мог бы теоретически вручную очистить 0-й бит, а затем прыгнуть, но я должен подумать об ошибке. Thunk генерируется компилятором C - правильно? Компилятор C знает, что thunk - это код ARM. Адрес в pFunc генерируется компоновщиком, так как это межмодульный вызов. Таким образом, младший бит помещается туда компоновщиком; почему линкер не знает, что эти трюки являются ARM?

Любые объяснения, пожалуйста?

У меня сейчас нет устройства WP8, поэтому я не могу попробовать его в реальном оборудовании. Ужасно глядя на сгенерированный код - это единственная технология отладки, которая у меня есть :(

EDIT: но что, если эти громкости не являются ARM, но Thumb-2? Thumb-2 поддерживает 32-разрядную команду IIRC. то же, что и в режиме ARM? Как все-таки декодируют команды Thumb-2?

Answer 1

Дисассемблер (в частности, IDA Demo) вводит меня в заблуждение, объединяя несколько команд в одну строку. Он сделал одну линию mov из последовательности mov-orr-orr, которая предназначалась для назначения полной 32-разрядной константы регистру. В конце концов, толчки были Thumbks. Компилятор работает так, как он был разработан.

IDA в отличном состоянии. В глубине души я знал об этом конкретном поведении в отношении ARM, но на этот раз он поскользнулся.

Неплохо, спасибо и поддержите всех, кто пытался помочь.

Answer 2

Подробности, которые вы хотите, указаны в разделе «A2.3.2. Псевдокод подробностей операций с основными регистрами ARM» в «Справочном руководстве по архитектуре ARM», ARMv7 . -А и ARMv7-R издание»Вот соответствующая псевдокод (из приведенного выше руководства) о записи в регистр PC:

BXWritePC(bits(32) address) 
    if CurrentInstrSet() == InstrSet_ThumbEE then 
     if address<0> == '1' then 
      BranchTo(address<31:1>:'0'); // Remaining in ThumbEE state 
     else 
      UNPREDICTABLE; 
    else 
     if address<0> == '1' then 
      SelectInstrSet(InstrSet_Thumb); 
      BranchTo(address<31:1>:'0'); 
     elsif address<1> == '0' then 
      SelectInstrSet(InstrSet_ARM); 
      BranchTo(address); 
     else // address<1:0> == '10' 
      UNPREDICTABLE; 

Если Ио бит бит (бит 0) установлен, процессор очистит этот бит, переключится в режим Thumb и выполнит переход к новому адресу.

Данное поведение верно для ARMv7 и более поздних версий (т. Е. Применимо ко всем устройствам Windows Phone, но не для всех устройств Android/iOS).

Answer 3

Возможно, у вас действительно есть действительная/настоящая проблема на вашей руке. Afaik Windows Phone - это required to be Thumb-2 only, поэтому использующий компоновщик, возможно, не сможет обрабатывать вызовы в режиме ARM. См. Ту же ссылку для некоторых соображений при смешивании сборки и C.

Если бы это был вопрос Linux/ELF, я бы ответил иначе;

Адрес под pFunc порождается линкера, так как это кросс-модуль вызова. Таким образом, младший бит размещается там компоновщиком.

pFunc порождается compiler и linker исправит его, когда вы создаете загружаемый образ, который уже будет полностью решена для статического перемещения вызовов.Все переносимые объектные файлы должны содержать таблицу о функциональных режимах, чтобы позднее компоновщики могли обрабатывать их и соответственно перемещать и обновлять последовательности вызовов.

См. ELF for the ARM Architecture - 4.6 Relocation, как это делается через ELF.