Ищете хороший способ определить правила для декомпилятора, нужен совет

Question

Я работаю над очень простым декомпилятором для архитектуры MIPS, и по мере продвижения я должен определить множество правил для анализа кода, например, «если этот код операции равен lui , а следующий код операции - addiu затем возвращает var = value"или", если этот код операции bne и он ссылается на адрес перед текущим - создайте определение loop в дереве синтаксического анализа " , Проблема в том, что существует множество таких правил, и я не могу найти хороший способ их определить. Я пробовал писать отдельные функции для каждого правила, определяя классы базовой ООП-логики и расширяя их для создания правил, даже пробовал регулярные выражения в дизассемблированном коде (к моему удивлению, это работает лучше, чем ожидалось), но независимо от того, что я пытался мой код вскоре стал большим и трудным для чтения, независимо от того, насколько хорошо я пытаюсь документировать и структурировать его.

Это подводит меня к выводу, что я пытаюсь решить эту задачу, используя неправильные инструменты (не говоря уже о том, что слишком глуп для такой сложной задачи :)), но у меня нет реальной идеи, что мне следует попробовать. В настоящее время у меня есть две непроверенные идеи: одна использует какой-то DSL (у меня нет абсолютно никакого опыта в этом, так что я могу быть совершенно неправым), а другая пишет какие-то бинарные регулярные выражения для сопоставления кода операции.

Я надеюсь, что кто-то может указать мне правильное направление, спасибо.

Answer 1

Я полагаю, что некоторые из ваших правил слишком низкоуровневые, и поэтому они становятся неуправляемыми.

Признание lui с последующим addiu 32-битной постоянной нагрузкой, безусловно, кажется очень разумным; но попытка получить поток управления из инструкций ветвления на уровне отдельного кода операции кажется более подозрительной - я думаю, что вы хотите работать с базовыми блоками там.

Cifuentes ' Методы обратной компиляции - это ссылка, которая постоянно появляется в обсуждениях декомпиляции, которые я видел; из довольно краткого обзора кажется, что стоит потратить некоторое время на подробное чтение вашего проекта.

Некоторые вещи, относящиеся к x86, не будут актуальны - в частности, этап, который переводит x86 в низкоуровневое промежуточное представление, вероятно, не является необходимым для MIPS (MIPS, по сути, является всего лишь одной базовой операцией для каждого кода операции) - но в остальном большая часть контента выглядит так, как будто она должна быть очень полезной.