больше информации о расположении Памяти исполняемой программы (процесс)
Я присутствовал на интервью относительно Samsung. Они спросили партию вопросов на расположении памяти программы. Я едва знаю что-либо об этом.
Я погуглил его "Расположение памяти исполняемой программы". "Расположение памяти процесса".
Я удивлен видеть, что нет большого количества информации об этих темах. Большинством результатов являются запросы форума. Я просто задаюсь вопросом почему?
Это несколько ссылок, которые я нашел:
- Организация устройства хранения данных во время выполнения
- Организация памяти во время выполнения
- Расположение памяти процесса C ^pdf^
Я хочу узнать об этом из надлежащей книги вместо некоторых ссылок на сайт. (Randy Hyde является также книгой, но некоторой другой книгой). В которой книге я могу найти ясным и больше информации об этом предмете?
Я также задаюсь вопросом, почему не сделал обложки книги операционных систем это в их книгах? Я считал остановки 6-й выпуск. Это просто обсуждает Блок управления процессом.
Это все создание расположения является задачей linker правильно? Где я могу читать больше об этом процессе. Я хочу ПОЛНУЮ информацию от программы на диске к его выполнению на процессоре.
Править:
Первоначально, я не был ясен даже после чтения ответов, данных ниже. Недавно, я столкнулся с этими статьями после чтения их, я понял вещи ясно.
Ресурсы, которые помогли мне в понимании:
- www.tenouk.com/Bufferoverflowc/Bufferoverflow1b.html
- 5 частей учебное руководство по формату файла PE: http://win32assembly.online.fr/tutorials.html
- Превосходная статья: http://www.linuxforums.org/articles/understanding-elf-using-readelf-and-objdump_125.html
- Проводник PE: http://www.heaventools.com/
Да, "расположение исполняемой программы (PE/ELF)"! = "Расположение памяти процесса"). Findout для себя в 3-й ссылке.:)
После очистки моих понятий мои вопросы заставляют меня выглядеть настолько глупым.:)
3 ответа
Как все загружается, очень сильно зависит от операционной системы и используемого двоичного формата, и подробности могут стать неприятными. Существуют стандарты того, как распределяются двоичные файлы, но на самом деле это зависит от операционной системы, как распределяется память процесса. Вероятно, именно поэтому документацию трудно найти.
Чтобы ответить на ваши вопросы:
- Книги:
- Если вас интересует, как процессы распределяют свою память, посмотрите Понимание ядра Linux. В 3-й главе рассказывается о дескрипторах процессов, создании процессов и их уничтожении.
- Единственная известная мне книга, посвященная линковке и загрузке, - это Linkers and Loaders Джона Левина. Есть онлайн и печатная версия, так что проверьте это.
Исполняемый код создается компилятором и компоновщиком, но именно компоновщик помещает вещи в двоичный формат, который нужен операционной системе. В Linux этот формат обычно ELF, в Windows и старых Unix'ах это COFF, а в Mac OS X это Mach-O. Но это не фиксированный список. Некоторые операционные системы могут поддерживать и поддерживают несколько бинарных форматов. Линкеры должны знать выходной формат для создания исполняемых файлов.
Расположение памяти процесса довольно похоже на двоичный формат, так как многие двоичные форматы рассчитаны на
mmap'd, так что задача загрузчика проще.Это не совсем , хотя и не так просто. Некоторые части двоичного формата (например, статические данные) не хранятся непосредственно в двоичном файле. Вместо этого двоичный файл просто содержит размер этих секций. Когда процесс загружается в память, загрузчик знает, как выделить нужный объем памяти, но двоичный файл не должен содержать больших пустых секций.
Кроме того, в компоновке памяти процесса есть место для стека stack и кучи heap, куда идут кадры вызова процесса и динамически выделяемая память. Обычно они живут на противоположных концах большого адресного пространства.
Это действительно просто царапает поверхность того, как загружаются двоичные файлы, и ничего не говорит о динамических библиотеках. Для более детального рассмотрения того, как работает динамическое связывание и загрузка, читайте How to Write Shared Libraries.
.Вот один из способов, как программа может быть выполнена из файла (*nix).
- Создается процесс (например, fork()). Это дает новому процессу свою собственную карту памяти. Это включает в себя стек в некоторой области памяти (обычно высоко в памяти где-то).
- Новый процесс вызывает exec() для замены текущего исполняемого файла (часто оболочки) на новый исполняемый файл. Часто новые исполняемые файлы .text (исполняемый код и константы) и .data (инициализированные переменные r/w) настраиваются на отображение страницы запроса, т.е. при необходимости они отображаются в пространстве памяти процесса. Часто на первом месте стоит раздел .text, за которым следуют .data. Часто после .data секции выделяется .bss-секция (неинициализированные переменные). Часто при первом обращении к странице, содержащей переменную bss, отображается страница с нулями. Куча часто начинается на границе следующей страницы после раздела .bss. Затем куча растет в памяти, в то время как стек растет вниз (помните, я говорил обычно, бывают исключения!)
Если куча и стек сталкиваются, то это часто приводит к ситуации вне памяти, поэтому стек часто размещается в большой памяти.
В системе без устройства управления памятью, пейджинг запросов обычно недоступен, но часто используется та же самая раскладка памяти.
.Искусство программирования на ассемблере http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/www.artofasm.com/Windows/PDFs/MemoryAccessandOrg.pdf