Где сегменты памяти определены?

Question

Я только что узнал о различных сегментах памяти, таких как: текст, данные, стек и куча. Мой вопрос:

1 - Где границы между этими разделами определены? Это в компиляторе или ОС?

2- Как компилятор или ОС знают, какие адреса принадлежат каждому разделу? Должны ли мы определить его где угодно?

Answer 1

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

Где указаны границы между этими разделами? Это в компиляторе или ОС?

Ни компилятор, ни ОС не делают этого. Это компоновщик, который определяет, где расположены разделы памяти. Компилятор генерирует объектные файлы из исходного кода. Компилятор использует файл сценария компоновщика для поиска объектных файлов в памяти. Файл сценария компоновщика (или директива компоновщика) является файлом, который является частью проекта, и определяет тип, размер и адрес различных типов памяти, таких как ПЗУ и ОЗУ. Программа-компоновщик использует информацию из файла сценария компоновщика, чтобы узнать, где начинается каждая память. Затем компоновщик находит каждый тип памяти из объектного файла в соответствующем разделе памяти. Например, код идет в разделе .text, который обычно находится в ПЗУ. Переменные идут в разделе .data или .bss, которые находятся в ОЗУ. Стек и куча также идут в ОЗУ. Когда компоновщик заполняет один раздел, он узнает размер этого раздела и может знать, с чего начать следующий раздел. Например, раздел .bss может начинаться там, где заканчивается раздел .data.

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

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

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

Как компилятор или ОС знают, какие адреса принадлежат каждому разделу?

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

Должно ли мы определить его в любом месте?

Просмотрите файл сценария компоновщика (или ссылку) и прочитайте руководство по компоновщику. Сценарий компоновщика вводится в компоновщик и обеспечивает грубые очертания памяти. Компилятор находит все в памяти и определяет степень каждого раздела.

Answer 2

Секции определяются форматом, который свободно привязан к ОС. Например, на Linux у вас есть ELF, а на Mac OS у вас есть Mach-O.

Вы не определяете разделы явно как программист, в 99,9% случаев. Компилятор знает, что положить туда.

Answer 3

Для вашего запроса: -

Где границы между этими участками определяются? Это в компиляторе или ОС?

Ответ - OS.

Нет общей универсальной схемы адресации для сегмента .text (исполняемый код), сегмента .data (переменные) и других сегментов программы. Однако компоновка самой программы хорошо сформирована в соответствии с системой (ОС), которая будет выполнять программу.

Как компилятор или ОС знают, какие адреса принадлежат каждому разделу? Должны ли мы определить его где угодно?

Я разделил свой этот вопрос на 3 вопроса: -

О тексте (код) и разделов данных и их ограничение?

Текст и данные подготовлены компилятором. Требование для компилятора состоит в том, чтобы убедиться, что они доступны и упаковывают их в нижнюю часть адресного пространства. Доступное адресное пространство будет ограничено оборудованием, например. если регистр указателя инструкции является 32-битным, тогда текстовое адресное пространство будет 4 GiB.

О разделе кучи и лимите? Это общая доступная оперативная память?

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

Есть ли у стека и кучи предел статического размера?

Последний сегмент в адресном пространстве процесса представляет собой стек. Стек занимает конечный сегмент адресного пространства и начинается с конца и растет.

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

Начинается с набора ограничений для кучи (стека) для каждого процесса. Этот предел можно изменить во время выполнения (используя brk()/sbrk()).В основном, что происходит, когда процессу требуется больше места для кучи, и у него закончилось выделенное пространство, стандартная библиотека выдает вызов ОС. ОС будет выделять страницу, которая, как правило, будет управляться библиотекой пользователя для используемой программы. То есть если программа хочет 1 KiB, ОС предоставит дополнительные 4 KiB, и библиотека предоставит 1 KiB программе и 3 KiB останется для использования, когда программа запросит больше в следующий раз.

В большинстве случаев макет будет представлять собой текст, данные, кучу (растет), нераспределенное пространство и, наконец, стек (растет). Все они имеют одинаковое адресное пространство.