Перекомпилируйте код x86 с LLVM на более быстрый x86

Можно ли запустить компилятор LLVM с вводом 32-битного кода x86? Существует огромный алгоритм, исходный код которого у меня отсутствует, и я хочу, чтобы он работал быстрее на том же оборудовании. Можно ли перевести с x86 обратно на x86 с оптимизацией.

Этот код работает долго, поэтому я хочу сделать его статическую перекомпиляцию. Кроме того, я могу сделать его профиль времени выполнения и дать подсказки LLVM, какие ветки более вероятны.

Исходный код написан для x86 + x87 и не использует SSE / MMX / SSE2. После перекомпиляции есть шанс использовать x86_64 и / или SSE3. Также код будет регенерирован более оптимальным образом в аппаратный декодер.

Спасибо.


llvm x86 recompile
person osgx    schedule 08.01.2011    source источник
comment
Это не ответ, но я помню, что для Amiga были программы для оптимизации кода, скомпилированного для MC68000, чтобы он работал быстрее на новых процессорах за счет совместимости. Но я не знаю такой попытки для x86.   -  person liori    schedule 09.01.2011
comment
ИМО, вам может быть лучше использовать что-то вроде IDA и шестнадцатеричных лучей или Ollydbg для обратного проектирования сборки обратно на язык более высокого уровня (C или C ++)   -  person Necrolis    schedule 28.11.2011
comment
RevGen является одним из трансляторов x86- ›LLVM здесь. Он также имеет переводчик с x86 на статический двоичный. Он использует Qemu и модифицированный MIPS TCG, который генерирует IR.   -  person osgx    schedule 28.03.2012
comment
Также существует dagger.repzret.org - кинжал, который может декомпилировать в LLVM IR.   -  person osgx    schedule 07.05.2013
comment
@osgx Боюсь, что кинжал никогда не выпустит ....   -  person lllllllllllll    schedule 12.01.2014
comment
Распространенным ключевым словом в настоящее время является подъем сборок: github.com/trailofbits/mcsema | github.com/zneak/fcd | reverseengineering.stackexchange.com/questions/12460/   -  person Ciro Santilli 新疆再教育营六四事件ۍ    schedule 02.05.2018

Ответы (3)


arrow_upward
13
arrow_downward

LLVM не может этого сделать из коробки. Вам нужно будет написать двоичный код x86 в преобразователь промежуточного представления LLVM (IR). Это была бы очень нетривиальная задача. Если бы код x86 был достаточно простым, он мог бы довольно точно соответствовать IR, но некоторые инструкции x86 не будут отображаться напрямую, например манипуляции с указателем стека.

Изменить: вы также можете попробовать подход, аналогичный тому, что делает QEMU. QEMU переводит двоичные файлы на лету, так что, когда я запускаю код PowerPC, каждый базовый блок транслируется в код X86 перед его выполнением. Вы могли бы выяснить, как разбить ваш объектный файл на базовые блоки и сгенерировать LLVM IR для каждого блока, отбросив все (например, передачу параметров и т. Д.) И заменив это прямым LLVM IR.

Тем не менее, это все еще БОЛЬШАЯ работа. Наверное, проще алгоритм переписать с нуля.

Этот точный процесс описан в «Динамический перевод x86 в LLVM с использованием QEMU "

person Richard Pennington    schedule 08.01.2011
comment
Есть ли такие же проекты? - person osgx; 09.01.2011
comment
Скорее всего, не. В машинном коде просто недостаточно информации для работы оптимизатора LLVM. Код нужно было бы реконструировать обратно до высокоуровневого представления, прежде чем его можно было бы с пользой векторизовать и перекомпилировать для 64-битной версии, а компиляторы просто не так хороши для выполнения выводов. Возможно, вы сможете использовать эмулятор x86, который выполняет динамическую перекомпиляцию, но вряд ли он сможет векторизовать математику, а накладные расходы сведут на нет любое повышение производительности. - person user57368; 09.01.2011
comment
Для накладных расходов: есть код, который я хочу быстро запустить. Я могу потратить 1 час на запуск оптимизатора, прежде чем запустить новый код. Цель - получить более быстрый код из более медленного. Процесс перекомпиляции должен выполняться статически, один раз. - person osgx; 09.01.2011
comment
и есть старый проект HP personals.ac.upc.edu/vmoya/ docs / bala.pdf, который выполняет динамическую перекомпиляцию собственного машинного кода, чтобы сделать его быстрее. - person osgx; 19.01.2011
comment
Насколько мне известно, таких проектов нет, но однажды был проект по использованию LLVM для JIT-компиляции кода для QEMU (code.google.com/p/llvm-qemu), который тесно связан. - person Daniel Dunbar; 23.01.2011

arrow_upward
1
arrow_downward

Кажется, что проект MAO выполняет часть того, что вы хотите (x86-> промежуточный язык).

edit: @osgx, вам нужно будет посмотреть на веб-сайте mao статус проекта и подробности о том, с какими программами они могут работать. (Хотя самомодифицирующийся код может оказаться сложной задачей.)

person mwb    schedule 27.11.2011
comment
Привет. Какой статус у МАО? С какой частью x86 / x86_64 он справится? Может ли он работать с самомодифицируемым кодом (например, упакованный UPX) - person osgx; 28.11.2011

arrow_upward
0
arrow_downward

Насколько я знаю, полностью правильно разобрать x86-код невозможно. Поскольку данные и код перемешаны, а также из-за инструкций переменной длины. Единственный способ правильно разобрать - это интерпретировать на лету.

person pythonic    schedule 27.03.2012
comment
интерпретация нужна только для самомодифицирующегося кода. Статический код легко дизассемблировать (любым дизассемблером). Работа с динамическим кодом возможна только при наличии перекомпилятора во время выполнения ИЛИ, если динамический код можно распаковать в статический код (в моем случае используется EXE, упакованный так же, как используется UPX, и его можно распаковать) - person osgx; 29.04.2012
comment
@osgx: это неправда. Например, методы десинхронизации могут легко запутать дизассемблеры. - person molnarg; 14.01.2014
comment
Что ж, технически это правда, но ничего стоящего инженерного дела не возможно на 100%. так по идее 100%? невозможно ... на практике, 99,98% очень возможно ... на самом деле это хорошо задокументировано о том, как преодолеть теоретические ограничения и получить ценный результат. - person J. M. Becker; 16.02.2015