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

Анализ основного дампа в розничной сборке часто требует сопоставления objdumpлюбого конкретного модуля и исходного кода. Обычно сопоставление дампа сборки с исходным кодом становится проблемой, если функция достаточно вовлечена. Сегодня я попытался создать assembly listingодного конкретного модуля (с опцией компиляции -S), ожидая, что увижу чередующийся исходный код со сборкой или какой-то корреляцией. К сожалению, листинг не был достаточно дружественным для сопоставления, поэтому мне было интересно

• Учитывая дамп ядра -, из которого я могу определить место сбоя
• objdumpнеисправного модуля Листинг сборки путем перекомпиляции модуля
• с -Sвариант.

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

В качестве примера я вижу листинг сборки как

.LBE7923:
       .loc 2 4863 0
        movq    %rdi, %r14
        movl    %esi, %r12d
        movl    696(%rsp), %r15d
        movq    704(%rsp), %rbp
.LBB7924:
       .loc 2 4880 0
        testq   %rdx, %rdx
        je     .L2680
.LVL2123:
        testl   %ecx, %ecx
        jle    .L2680
        movslq  %ecx,%rax
       .loc 2 4882 0
        testl   %r15d, %r15d
       .loc 2 4880 0
        leaq    (%rax,%rax,4), %rax
        leaq    -40(%rdx,%rax,8), %rdx
        movq    %rdx, 64(%rsp)

, но не могу понять, как интерпретировать метки типа .LVL2123и директивы вроде.loc 2 4863 0

Примечание Судя по ответам,чтение исходного кода сборки и интуитивное определение шаблона на основе символов (, таких как вызовы функций, переходы, оператор возврата ), — это то, что я обычно делаю. Я не отрицаю, что это не работает, но когда функция очень вовлечена, чтение страниц листинга сборки вызывает боль, и часто вы получаете листинг, который редко совпадает либо из-за функций, попадающих в -, выровненных, либо из-за того, что оптимизатор имеет просто подкинул код как ему вздумается. У меня такое ощущение, что, видя, насколько эффективно Valgrindобрабатывает оптимизированные двоичные файлы и как в Windows WinDBG может обрабатывать оптимизированные двоичные файлы, я что-то упускаю. Поэтому я решил начать с вывода компилятора и использовать его для корреляции. Если мой компилятор несет ответственность за искажение двоичного файла, лучше всего будет сказать, как соотнести его с исходным кодом, но, к сожалению, это было наименее полезным, а .locдействительно вводит в заблуждение. К сожалению, мне часто приходится читать невоспроизводимые дампы на разных платформах, и меньше всего времени я трачу на отладку дампов Windows Mini -через WinDBG и значительное время на отладку Linux Coredumps. Хотя, может быть, я что-то делаю не так, поэтому я придумал этот вопрос.