Детерминированные сборки под Windows ⇐ C++

[Anonymous]

Конечная цель — сравнить два двоичных файла, созданных из одного и того же источника в одной и той же среде, и определить, что они действительно функционально эквивалентны.
Одним из приложений для этого может быть сосредоточение времени QA на вещах, которые действительно были изменены между выпусками, а также мониторинг изменений в целом.
MSVC в тандеме с форматом PE, естественно, делает это очень трудным.
Пока я нашел и нейтрализовал их. вещи:

• Временная метка и контрольная сумма PE
• Запись каталога цифровой подписи
• Временная метка раздела отладчика
• Подпись PDB, возраст и путь к файлу
• Временная метка ресурсов
• Все версии файлов/продуктов в ресурсе VS_VERSION_INFO
  />
• Раздел цифровой подписи

Я анализирую PE, нахожу смещения и размеры для всех этих вещей и игнорирую диапазоны байтов при сравнении двоичных файлов. Работает отлично (ну, в тех немногих тестах, которые я провел). Я могу сказать, что подписанный исполняемый файл версии 1.0.2.0, созданный на Win Server 2008, равен неподписанному исполняемому файлу версии 10.6.6.6, созданному на моем компьютере для разработчиков Win XP, при условии, что версия компилятора, все исходные коды и заголовки одинаковы. Кажется, это работает для VC 7.1-9.0. (Для релизных сборок)
С одной оговоркой.
Абсолютные пути для обеих сборок должны быть одинаковыми должны иметь одинаковую длину.

Код: Выделить всё

cl.exe

преобразует относительные пути в абсолютные и помещает их прямо в объекты вместе с флагами компилятора и так далее. Это оказывает непропорциональное влияние на весь двоичный файл. Одно изменение символа в пути приведет к тому, что один байт будет изменен здесь и там несколько раз во всем разделе .text (я подозреваю, что многие объекты были связаны). Изменение длины пути приводит к значительно большему количеству различий. Как в файлах obj, так и в связанных двоичных файлах.
Ощущение, что путь к файлу с флагами компиляции используется как своего рода хеш, который превращает его в связанный двоичный файл или даже влияет на порядок размещения несвязанных фрагментов скомпилированного кода.
Итак, вот вопрос из трех частей (обобщенный как «что теперь?»):

• Должен ли я отказаться от всего проекта и пойти домой из-за того, что я пытаюсь сделать? нарушает законы физики и корпоративную политику MS?
• Предполагая, что я решаю проблему с абсолютным путем (на уровне политики или путем поиска магического флага компилятора), есть ли еще какие-то вещи, на которые мне следует обратить внимание? (такие вещи, как __TIME__ do, означают измененный код, поэтому я не возражаю против того, чтобы их не игнорировали)
• Есть ли способ заставить компилятор использовать относительные пути или обмануть его, заставив думать, что путь не тот, что есть?

Причиной последнего является прекрасное раздражение файловой системы Windows. Никогда не знаешь, когда удаление источников и объектов на несколько гигабайт и метаданных svn завершится неудачей из-за мошеннической блокировки файла. По крайней мере, создание нового корня всегда удается, пока есть место. Запуск нескольких сборок одновременно также является проблемой. Запуск группы виртуальных машин, хотя и является решением, является довольно трудным.
Интересно, есть ли способ настроить виртуальную файловую систему для процесса и его дочерних элементов, чтобы несколько деревьев процессов одновременно видели _различные_директории "C:\build", частные только для них... Своего рода облегченная виртуализация...
ОБНОВЛЕНИЕ: недавно мы открыли исходный код этого инструмента на GitHub. См. раздел Сравнение в документации.

Подробнее здесь: https://stackoverflow.com/questions/118 ... er-windows