Проверка двух разных архитектур сборки (одна переписывает другую) функционально эквивалентна

Question

Я переписываю сборку, которая производит несколько вещей (разделяемые / статические библиотеки, файлы jar, исполняемые файлы и т. Д.).Возник вопрос, есть ли способ проверить, что результаты являются функционально эквивалентными, не выполняя полный тест сверху вниз получающегося программного обеспечения.

Однако это оказывается более трудным, чем яОжидается.

В качестве примера я ожидал, что md5 двух объектов, созданных из одного источника (компилятор sun studio C ++) и параметры командной строки, будут иметь одинаковый хэш md5, но это не так,Я могу собрать файл, переименовать его, собрать снова, и они имеют разные хэши.

С учетом сказанного ... есть ли способ сделать быструю проверку, чтобы убедиться, что два файла созданы из отдельных архитектур компоновкиодно и то же дерево исходных текстов (например, два общих объекта) функционально эквивалентны?

edit Извините, я не упомянул, что это для отладочной сборки ... когда флаги отладки неиспользуемые двоичные файлы идентичны, но они используют флаги отладки по умолчанию в течение многих лет, и их содержимое перестает работать, когда вы удаляете флаги отладки (одна из причин, по которой я переписываю сборку, состоит в том, чтобы воспользоваться этой конкретной «функцией»)вне сборки, чтобы мы могли провести правильное тестирование)

Answer 1

Windows DLL имеют метку времени ссылки ( TimeDateStamp ) как часть образа PE.

Глядя на опции компоновщика , я не вижу возможности подавить это. Поэтому повторное связывание DLL (или EXE) всегда будет приводить к другому бинарному файлу.

Вы могли бы написать инструмент для обнуления этих временных отметок (всегда с фиксированным смещением от начала файла) и впоследствии сравнивать MD5. Но вы, вероятно, также обнаружите много других отличий. В частности, любая программа, использующая встроенные функции __DATE__ или __TIME__, доставит вам неприятности.

Нам пришлось приложить немало усилий, чтобы добиться идентичных битов перестраиваний (используя набор инструментов GNU). Это возможно (по крайней мере, для инструментов с открытым исходным кодом в Linux), но не так просто (как вы обнаружили).

Answer 2

Я забыл об этом вопросе; Я возвращаюсь, чтобы дать ответ, который придумал.

objcopy может использоваться для создания нового двоичного файла в различных форматах. Прошло несколько лет с тех пор, как я работал над этим, поэтому подробности меня избегают, но вот что я помню:

objcopy может удалять различные вещи (отладочную информацию, символьную информацию и т. Д.), Но даже после удаления я все еще видел различные хэши между объектами.

В конце концов я обнаружил, что могу конвертировать его из ELF в другие форматы. Я закончил тем, что выгрузил его в другой формат (я думаю, что я выбрал SREC), который последовательно предоставлял один и тот же MD5 для объектов, построенных в разное время с одинаковым источником / флагами.

Бьюсь об заклад, я мог бы сделать это лучше с objcopy (или, возможно, другим binutils инструментом), но этого было достаточно, чтобы удовлетворить наши опасения.