Что происходит в сборке Apple LLVM-gcc x86?

Поскольку вопрос на самом деле касается этих странных меток и данных, а не самого кода, я только собираюсь пролить на них свет.

Если инструкция программы вызывает ошибку выполнения (такую ​​как деление на 0 или доступ к недоступной области памяти или попытка выполнить привилегированную инструкцию), она приводит к исключению (не типу исключения C++, а типу прерывания). его) и заставляет ЦП выполнять соответствующий обработчик исключений в ядре ОС. Если бы мы полностью запретили эти исключения, история была бы очень короткой, ОС просто завершила бы программу.

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

В любом случае полезно знать следующее:

• функция, в которой произошло исключение, а не только инструкция в ней
• функция, вызвавшая эту функцию, функция, вызвавшая ту и т. д.

и возможно (в основном для отладки):

• строка файла исходного кода, из которого была сгенерирована эта инструкция
• строки, где были сделаны эти вызовы функций
• параметры функции

Зачем нам нужно знать дерево вызовов?

Ну, а если программа регистрирует собственные обработчики исключений, то обычно она делает что-то вроде блоков C++ try и catch:

fxn()
{
  try
  {
    // do something potentially harmful
  }
  catch()
  {
    // catch and handle attempts to do something harmful
  }
  catch()
  {
    // catch and handle attempts to do something harmful
  }
}

Если ни один из этих catches не перехватывает, исключение распространяется на вызывающую сторону fxn и потенциально на вызывающую сторону вызывающей стороны fxn до тех пор, пока не появится catch, который перехватит исключение, или пока обработчик исключений по умолчанию просто не завершит программу.

Итак, вам нужно знать области кода, которые покрывает каждый try, и вам нужно знать, как добраться до следующего ближайшего try (например, в вызывающем fxn), если непосредственный try/catch не перехватывает исключение и оно приходится пузыриться.

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

И вы не всегда можете полагаться на то, что rbp+8 указывает на адрес возврата в стеке, потому что компилятор может оптимизировать код таким образом, что rbp больше не участвует в доступе к параметрам функции и локальным переменным. Вы можете получить к ним доступ и через rsp+something и сохранить регистр и несколько инструкций, но с учетом того, что разные функции выделяют разное количество байт в стеке для локалов и параметров, передаваемых другим функциям, и настроить rsp по-разному, просто значение rsp недостаточно, чтобы узнать обратный адрес и вызывающую функцию. rsp может быть произвольным числом байтов от адреса возврата в стеке.

Для таких сценариев компилятор включает дополнительную информацию о функциях и использовании их стека в специальном разделе исполняемого файла. Код обработки исключений проверяет эту информацию и правильно раскручивает стек, когда исключения должны распространяться на вызывающие функции и их блоки try/catch.

Таким образом, данные, следующие за _main.eh, содержат эту дополнительную информацию. Обратите внимание, что он явно кодирует начало и размер main(), ссылаясь на Leh_func_begin1 и Leh_func_end1-Leh_func_begin1. Эта часть информации позволяет коду обработки исключений идентифицировать инструкции main()'s как main()'s.

Также кажется, что main() не очень уникальна, и часть его информации о стеке/исключении такая же, как и в других функциях, и имеет смысл делиться ею между ними. Итак, есть ссылка на Leh_frame_common.

Я не могу комментировать структуру _main.eh и точное значение таких констант, как 144 и 13, так как не знаю формата этих данных. Но, как правило, эти подробности знать не нужно, если только они не являются разработчиками компилятора или отладчика.

Я надеюсь, что это дало вам представление о том, для чего нужны эти метки и константы.

Хорошо, давайте попробуем

// Первый раздел кода, объявляющий основную функцию, которая должна быть выровнена по 32-битной границе.

ОБНОВЛЕНИЕ: мое объяснение директивы .align может быть неверным. См. документацию по газу ниже.

.section    __TEXT,__text,regular,pure_instructions
.globl  _main
.align  4, 0x90
_main:

Сохраните предыдущий базовый указатель и выделите место в стеке для локальных переменных.

Leh_func_begin1:
pushq   %rbp
Ltmp0:
movq    %rsp, %rbp
Ltmp1:
subq    $32, %rsp
Ltmp2:

Поместите аргументы в стек и вызовите puts()

movl    %edi, %eax
movl    %eax, -4(%rbp)
movq    %rsi, -16(%rbp)
leaq    L_.str(%rip), %rax
movq    %rax, %rdi
callq   _puts

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

movl    $0, -24(%rbp)
movl    -24(%rbp), %eax
movl    %eax, -20(%rbp)
movl    -20(%rbp), %eax
addq    $32, %rsp
popq    %rbp
ret
Leh_func_end1:

Следующий раздел, а также раздел кода, содержащий строку для печати.

.section    __TEXT,__cstring,cstring_literals
L_.str:
.asciz   "Hello, World!"

Остальное мне неизвестно, могут быть данные, используемые как код запуска c или информация об отладке.

.section    __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
...

ОБНОВЛЕНИЕ: Документация по директиве .align из: http://sourceware.org/binutils/docs-2.23.1/as/Align.html#Align

«Способ указания требуемого выравнивания зависит от системы. Для дуг, hppa, i386 с использованием ELF, i860, iq2000, m68k или 32, s390, sparc, tic4x, tic80 и xtensa первое выражение — это запрос выравнивания в байт. Например, `.align 8' продвигает счетчик местоположения до тех пор, пока он не станет кратным 8. Если счетчик местоположения уже кратен 8, никаких изменений не требуется. Для tic54x первое выражение представляет собой запрос выравнивания в словах .

Для других систем, включая ppc, i386, использующих формат a.out, arm и strongarm, это количество младших нулевых битов, которое счетчик местоположения должен иметь после продвижения. Например, `.align 3' продвигает счетчик местоположений до тех пор, пока оно не станет кратным 8. Если счетчик местоположений уже кратен 8, никаких изменений не требуется.

Это несоответствие связано с различным поведением различных собственных ассемблеров для этих систем, которые должен эмулировать GAS. GAS также предоставляет директивы .balign и .p2align, описанные ниже, которые имеют одинаковое поведение во всех архитектурах (но специфичны для GAS)».

//jk

Вы можете найти ответы практически на любые вопросы, связанные с директивами здесь и здесь.

Например:

.section    __TEXT,__text,regular,pure_instructions

Объявляет раздел с именем __TEXT,__text с типом раздела по умолчанию и указывает, что этот раздел будет содержать только машинный код (т. е. без данных).

.globl _main
Делает метку (символ) _main глобальной, чтобы она была видна компоновщику.

.align 4, 0x90
Выравнивает счетчик местоположения по границе следующего 2^4 (==16) байта. Пространство между ними будет заполнено значением 0x90 (==NOP).

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