icbook 20 мар 2014 в 15:55

Организация вызова x86-процедур из EFI Byte Code

6 мин

7.2K

Ненормальное программирование*

+23

Комментарии 13

icbook 20 мар 2014 в 17:24

Исправлена ошибка верстки, вызванная некорректной вставкой изображений.

datacompboy 20 мар 2014 в 20:09

почему не вставить код текстом, используя тег <source>?

icbook 20 мар 2014 в 22:01

Изначально не планировалось публиковать на Хабре. В последний момент решили выложить скриншоты. Исходный код тоже подверстаем, но чуть позже. Спасибо за понимание :)

icbook 21 мар 2014 в 13:45

fixed

datacompboy 21 мар 2014 в 14:09

эм. а расцветки для асма нет? <source lang="asm"> хотя бы комменты подсвечивает…

icbook 21 мар 2014 в 16:56

Изначально указано lang=«Assembler», замена на lang=«asm» визуализацию не улучшает ((

datacompboy 21 мар 2014 в 17:29

        PUSH64		R7			; Storage for output
        MOVQ		R7,R0			; Address of storage = stack pointer
        PUSHN		R7			; Parameter#2 = Output address
        PUSHN		R6			; Parameter#1 = MSR address

таки разница есть. хм… но всё равно отвратно.
уже жалею что предложил заменить скриншоты ^_^

icbook 21 мар 2014 в 17:35

Ссылка на скриншоты осталась по тексту после Рис 1. и Рис 2.

qehgt 20 мар 2014 в 17:44

Непонятно, зачем это нужно. В чём сложность иметь разные бинарники для разных платформ? Ваше приложение всё равно не сможет работать на незнакомой архитектуре, а если список поддерживаемых архитектур предопределён — зачем всё так усложнять?

icbook 20 мар 2014 в 20:03

Один бинарник под все архитектуры — это удобное и изящное решение, позволяющее избежать проблем с конфигурированием, собенно если этот бинарник «прошит» в ПЗУ карты-адаптера. Изначально, EFI Byte Code разрабатывался именно для этого. Возможность писать на EBC загружаемые приложения — просто дополнительный бонус.

Приложение может запуститься на незнакомой архитектуре, если до распознавания архитектуры оно работает в минимальном режиме, взаимодействуя только с системными таблицами и UEFI-объектами.

qehgt 20 мар 2014 в 20:09

Понятно, спасибо.

CodeRush 20 мар 2014 в 17:53

Метод этот применять не стоит вообще, я думаю.
Вместо него стоит выделить платформозависимый код в отдельный DXE-драйвер и вызывать этот самый код через стандартные механизмы взаимодействия. Драйвер не загружен — до свиданья, никакого неопределенного поведения при запуске на ARM.

icbook 20 мар 2014 в 22:53

Если загрузчик, стартующий до вызова драйвера, должен быть кроссплатформенным, то он пишется не в нативном коде, а с использованием EFI Byte Code. DXE-драйверы, поддерживающие конкретные платформы, как правило, используют нативный код. Следовательно, мы вернулись к ситуации, рассмотренной в статье:

вызывающая процедура: EBC
вызываемая: нативный код

Зарегистрируйтесь на Хабре, чтобы оставить комментарий