Сопоставление исходного кода с листингом сборки программы C++

Можно ли вести индивидуальную переписку с источником?

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

Если я дизассемблирую код релиза, я смотрю на инструкции, которые должны иметь четкую логическую связь с кодом. Например,

.LBB7924:
        .loc 2 4880 0
        testq   %rdx, %rdx
        je      .L2680

выглядит как ветвь, если %rdx равно нулю, и исходит из строки 4880. Найдите строку, определите тестируемую переменную, отметьте, что в настоящее время она назначена %rdx.

.LVL2123:
        testl   %ecx, %ecx
        jle     .L2680

Итак, этот тест и ветвь имеют одну и ту же цель, поэтому все, что будет дальше, будет знать, что %rdx и %ecx оба отличны от нуля. Исходный код может быть структурирован следующим образом:

if (a && b) {

или, возможно, это было:

if (!a || !b) {

и оптимизатор переупорядочил две ветки...

Теперь у вас есть некоторая структура, которую вы, надеюсь, сможете сопоставить с исходным кодом, вы также можете выяснить назначение регистров. Например, если вы знаете, что тестируемая вещь является элементом данных некоторой структуры, прочитайте назад, чтобы увидеть, где %rdx был загружен из памяти: был ли он загружен с фиксированного смещения в какой-то другой регистр? Если да, то этот регистр, вероятно, является адресом объекта.

Удачи!

Директива .loc — это то, что вам нужно. Они обозначают строки #4863, 4880 и т. д. Не существует идеального соответствия между исходным кодом и оптимизированным ассемблером (именно поэтому вы видите 4880 более одного раза). Но .loc это то, как вы узнаете, где оно находится в файле. Синтаксис:

.loc <file> <line> <column>

Если вы не используете статические ссылки на системные библиотеки, даже без символов отладки в двоичном файле будут символические имена - имена функций системной библиотеки, с которыми связаны.

Это часто может помочь сузить ваше место в коде. Например, если вы видите, что в функции foo() она вызывает open(), а затем ioctl(), а затем происходит сбой прямо перед вызовом read(), вы, вероятно, легко найдете эту точку в исходном коде foo. (В этом отношении вам может даже не понадобиться дамп - в Linux вы можете получить запись о возникновении сбоя относительно библиотечных и системных функций, используя ltrace или strace)

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

Но, как уже упоминалось, если у вас есть исходный код и система, в которой он дает сбой достаточно часто, чтобы быть полезным, самым быстрым вариантом обычно будет перестроение с символами отладки или вставка вывода журнала и получение более полезной записи о сбое.