вы, по сути, компилируете один и тот же код с помощью двух разных компиляторов, конечно, компиляторы могут исходить из одного и того же исходного кода, но созданы для выполнения другой работы и выполняют другую работу. Вы не можете ожидать, что исполняемые файлы будут совпадать, ошибка здесь — это ваше ожидание.
Можно надеяться, что «все, что вам нужно сделать», это перевернуть некоторые адреса и перевернуть все данные байтов и полуслов, но в остальном иметь один и тот же двоичный файл. Вот одна очень простая проблема с этой теорией. Допустим, есть байт, к которому компилятор хочет получить доступ, и он находится по адресу 0x100000 с использованием одного порядка байтов. одна инструкция lui может загрузить этот адрес в регистр для последующего чтения байта. Если по какой-либо причине изменение порядка байтов заставляет этот адрес нуждаться в младших битах, например, 0x100003, теперь требуется две инструкции для загрузки этого адреса в регистр и/или ячейку памяти и однократное чтение этой ячейки памяти. Должна быть возможность сделать компилятор, целью которого является независимость от индии до последнего возможного момента, генерировать код без байтов (загружать все адреса в регистры, используя слово загрузки из .text, не использовать немедленную загрузку), а затем каким-то образом отслеживать все это и патч это в конце. Вы должны спросить, почему кто-то захочет сделать такой компилятор, это такой маленький вариант использования, чтобы не тратить время. Обычно вам нужна производительность вашего компилятора, а не что-то вроде этого.
Возьмите ваши скомпилированные программы, либо дизассемблируйте, либо objcopy в двоичный файл, затем сравните два двоичных файла, вы должны быстро увидеть, где они расходятся, а затем используйте дизассемблирование, описанное выше, вероятно, не конкретный пример, а что-то в этом роде. Как только один компилятор должен добавить один байт, слово или инструкцию, а не другой (при условии, что в остальном компиляторы были идентичными, а они не являются), изменение адресации может и вызовет больше различий в инструкциях, что приведет к тому, что двоичные файлы будут продолжать работать. расходиться.
person
old_timer
schedule
02.07.2012
