McSema и декомпиляция в исходный код LLVM: реально ли это?

[sl4v]

А вы пробовали какие-нибудь реальные бинарники транслировать с LLVM с помощью этой штуки? Они работают после этого?

[32bit_me]

Лично я не пробовал, потому что у меня нет IDA Pro, а разбираться с альтернативами долго и сложно. Но парни из одной компании пробовали, и любезно предоставили мне результаты (дизассемблированный бинарник, LLVM IR до оптимизации и после оптимизации). По их словам, они пробовали компилировать под Cortex A57, у них получилось около 1% производительности по сравнению с исходным вариантом (под x86-64). К сожалению, подробностей об условиях и методах тестирования мне неизвестно.

[AndNotNor]

Вместо обещанного семантического анализа мы имеем просто очень неэффективную эмуляцию работы процессора. Такой подход в принципе не позволяет добиться эффективной работы программы на процессоре с другой архитектурой.

Поспешный вывод вы сделали, кмк. Вы знаете что clang тоже генерит не оптимизированный llvm ir, где все переменные выделяются на стеке? Превратить это в операции с регистрами (и много чего еще) задача последующих оптимизаций на уровне IR и на уровне кодогенерации из IR в исполняемый код целевой платформы.

http://www.llvm.org/docs/Passes.html

[32bit_me]

Вы знаете что clang тоже генерит не оптимизированный llvm ir, где все переменные выделяются на стеке?

Да, знаю. Посмотрите ещё раз внимательно приведённый в статье код до оптимизации и после.
Оптимизатор удалил стековые копии «симулируемых регистров», и всё, что он сейчас может сделать, это вычислять адрес через операции с «виртуальным» регистром RSP и делать операции load/store volatile с полученным адресом. Обращения к волатильным переменным не могут быть удалены оптимизатором, а неволатильными их сделать тоже нельзя, потому что McSema ничего не знает о реальных переменных исходной программы.

Надеюсь. такое объяснение понятно. Если нет, попробуйте вникнуть в приведённый код, до оптимизации и после.