Дополнительная информация о макете памяти исполняемой программы (процесса)

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

Чтобы ответить на ваши вопросы:

1. Книги:
   • Если вы заинтересованы в том, как процессы выкладывают свою память, посмотрите на « Понимание ядра Linux» . В главе 3 рассказывается о дескрипторах процессов, создании процессов и разрушающих процессах.
   • Единственная книга, которую я знаю о том, что касается ссылок и загрузки в деталях, это Linkers and Loaders от John Levine. Там есть онлайн-версия и версия для печати, поэтому проверьте это.

2. Исполняемый код создается компилятором и компоновщиком, но это компоновщик, который помещает вещи в бинарный формат, который требуется ОС. В Linux этот формат, как правило, ELF , для Windows и более старых Unix – это COFF , а для Mac OS X это Mach-O . Однако это не фиксированный список. Некоторые ОС могут поддерживать и поддерживать несколько двоичных форматов. Линкерам необходимо знать выходной формат для создания исполняемых файлов.

3. Макет памяти процесса похож на двоичный формат, потому что многие бинарные форматы предназначены для mmap'd так что задача загрузчика проще.

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

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

Это действительно просто царапает поверхность загрузки двоичных файлов, и она не покрывает ничего о динамических библиотеках. Для подробного описания работы динамической компоновки и загрузки читайте « Как писать общие библиотеки» .

Вот один из способов, которым программа может быть выполнена из файла (* nix).

• Процесс создается (например, fork ()). Это дает новому процессу собственную карту памяти. Это включает стек в некоторой области памяти (обычно где-то в памяти).
• Новый процесс вызывает exec (), чтобы заменить текущий исполняемый файл (часто оболочку) новым исполняемым файлом. Часто для отображения страницы запроса настраиваются новые исполняемые файлы .text (исполняемый код и константы) и .data (r / w инициализированные переменные), то есть они отображаются в пространство памяти процесса по мере необходимости. Часто сначала начинается раздел .text, за которым следует .data. Раздел .bss (неинициализированные переменные) часто выделяется после раздела .data. Много раз он сопоставляется для возврата страницы нhive, когда страница, содержащая переменную bss, сначала открывается. Куча часто начинается с границы следующей страницы после раздела .bss. Затем куча растет в памяти, когда стек растет (помните, что я сказал обычно, есть исключения!).

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

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

Искусство сборки программного обеспечения http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/www.artofasm.com/Windows/PDFs/MemoryAccessandOrg.pdf