Адресация переменных и всей структуры программы на реальной памяти в ОС

Доброго времени суток, Вопрос по памяти, не совсем понятно:
1. Я написал программу 1.cpp, выполняю ее компиляцию, если я не использую динамическое выделение памяти, то при ее компиляции, исходя из объявленных переменных и еще чего-то там(?????), вычисляется объем памяти, требуемый для выполнения программы, затем происходит линковка - компоновка написанной программы, адресация каждой инструкции и разрешение имен для ф-ций(их адресация) . Линкер делает адресацию относительно "нуля" всего блока инструкций. Таким образом получается исполняемый файл - блок инструкций с рассчитанным, для его выполнения, объемом данных, у которого каждая инструкция теперь имеет адрес и за именем ф-ции скрывается адрес.

2. При запуске такого файла, ОС выделяет память, рассчитанную при компиляции и загружает программу в какую-то область оперативки с адресом X, где X и является по-сути тем самым "нулем" программы. ОС настраивает процессор на выполнение 1-ой инструкции и начинается ее выполнение, как только он доходит до инстр. вызова ф-ции, он кладет в IP адрес след.инструкции (в стек?) и переходит по адресу, который был дан ф-ции при линковке, передавая пар-ры этой ф-ции в стек обл-ти памяти где лежит наша программа. (Как этот стек выделяется? Это часть памяти, рассчитанной при компиляции? ) , затем ф-ция выполняется, работая с лок. переменными, которые лежат в том же стеке, и дойдя до return из стека (IP???) выдергивается адрес возврата и "процессор возвращается с каким - то значением".

3. При использовании динамического выделения, у нас и статическая память будет иметь место, в которой будет храниться выполняемая программа? и в процессе выполнения программы, дойдя до инструкции malloc (new), происходит выделение дин.памяти "где-то" в опер. памяти.
Верно ли я понимаю, скорректируйте, пожалуйста))))

Хочу понять и иметь общее представление о данном процессе) Буду очень рад, если кто-нибудь возьмется написать поэтапно все это)))

2

Все адреса в программе внутренние. Физический вообще, наверное, только в самом процессоре есть.
И что за защита стека указателями? Ты про его ограниченный размер, что ли? Ну указатель 4/8 байт, а выделить памяти по нему можно много, она же вне стека.

0

Сообщение от prado777 3 шаг. Добавляем лок. переменные ф-ции frab() в стек и передаем ей управление ( fp и sp переместились). Почему ret_val, ret_val, regist занимают всего, судя по смещениям, 4 байта???

Потому что показывайте как считали смешения.
1) Принцип as if говорит что наблюдаемое поведение программы должно совпадать с ее исходником. То есть, frab должно вернуть x+y. А вот локальные переменные компилятор имеет право выкинуть или наоборот добавить.
2) Компилятор никому не обязан хранить локальные переменные в стеке, если они помещаются в регистрах. Где на всех набрать регистров это уже другой вопрос.

Сообщение от prado777 6.Операция взятия адреса & показывает физ. адрес или номер страницы в таблице страниц?

Виртуальный адрес.

Сообщение от prado777 7. Тут мы передаем пар-ры (копии лок.переменных), которые имеют другой адрес. А когда используем указатель, то используем адрес на лок. переменную в main(), не создавая копию для передачи, но ведь указатель то все равно нужно сохр. в стеке, то есть это те же 32 бита (для 32 х разр), так как же указатели защищают от переполнения стека?

А кто сказал что указатели защищают от переполнения стека? Единственное что если переменная больше указателя на нее, стек жрется не так активно. Но жрется все равно.

0

Сообщение от prado777 2 шаг.

В стеке сохраняются еще адрес возврата и, возможно, состояния регистров, используемых в функции.

Сообщение от prado777 6.Операция взятия адреса & показывает физ. адрес или номер страницы в таблице страниц?

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

Сообщение от prado777 как же указатели защищают от переполнения стека?

Они защищают не для простых типов данных, а для здоровенных структур, классов или массивов. Представьте структуру размером 1000 байт. Одно дело пропихивать ее через стек и другое - только 4/8 байт указателя на нее же.

0

1. Считал я смещения так: пользовался для каждой переменной операцией взятия адреса &. Затем переводил из (hex) в (dec) // мне так пока что понятнее// и у каждой переменной получилось такое смещение. Я то думал, что при компиляции все идет линейно: от базового адреса добавляются смещения, в зависимости от размера переменной, но в моем примере этого не заметил я, тут вроде бы эта "линейность" в начале, а потом смещения уже пар-ов ф-ции Frab() другие, потом снова идет эта "линейность" с шагами на размер переменной. Вот почему так?

Может 472 - это уже другая "страница" виртуальной памяти?? Которая, как мы с Вами говорили,
находится уже в другом месте физической памяти, так? А та уже забилась.

2.

Сообщение от Renji 2) Компилятор никому не обязан хранить локальные переменные в стеке, если они помещаются в регистрах. Где на всех набрать регистров это уже другой вопрос.

А стек это не набор регистров, которые очищаются и записываются по воле процессора? Не понятно!

3.

Сообщение от Renji То есть, frab должно вернуть x+y. А вот локальные переменные компилятор имеет право выкинуть или наоборот добавить.

, так вот в шаге 4 - они "выкидываются"

0

Сообщение от prado777 А стек это не набор регистров, которые очищаются и записываются по воле процессора? Не понятно!

Разумеется, нет. Стек это область оперативной памяти. Обычно он ее использует именно как стек (LIFO, последний вошел первый вышел), но также в этой области хранятся локальные переменные, причем в обход стекового механизма, то есть стек знать не знает что к каким-то его элементам есть прямой доступ.

Сообщение от prado777 Может 472 - это уже другая "страница" виртуальной памяти?? Которая, как мы с Вами говорили,

Вряд ли. Внутри программы адресация линейна. Более вероятно что помимо локальных переменных в стеке сохраняются регистры процессора и какая-то еще служебная информация.

0

Сообщение от prado777 Может 472 - это уже другая "страница" виртуальной памяти?? Которая, как мы с Вами говорили, находится уже в другом месте физической памяти, так? А та уже забилась.

Последовательность виртуальных адресов не зависит от распределения физических адресов

Сообщение от prado777 2. А стек это не набор регистров, которые очищаются и записываются по воле процессора? Не понятно!

Стек это раздел выделенной памяти. У каждого процесса свой стек, причем для каждого процесса или потока может быть отдельный стек для пользовательского режима и для режима ядра. Зависит от ОС

0

То есть Вы хотите сказать, что лок. переменные хранятся в стеке, но доступ к ним не через LIFO, а прямой. И Получается все лок. переменные из стека удаляются, кроме лок. переменных main() // при вызовах только из main()//

0

Программе доступны две области памяти: стек и куча.
С кучей все понятно - программа запрашивает выделение кусков памяти под переменные с помощью malloc/free или new/delete, после чего ОС выдает ей их адреса (или не выдает в случае ошибки). Произвольного доступа к куче нет. Вы не можете напрямую писать, скажем, по адресу 0x1234. Зато динамическим выделением можно получить от ОС огромные куски памяти, даже больше чем есть оперативки в железе (механизм подкачки).
Стек же это служебная непрерывная структура данных. Основное предназначение это сохранение и восстановление при входе в подпрограммы. При этом сохраняются как минимум адрес возврата и состояние регистров процессора. Причем это происходит именно через стековый механизм: они кладутся на стек, а когда надо - по одному снимаются. По историческим причинам стек растет вниз - от конца доступной памяти к началу. Чтобы локальные переменные разных функций (особенно при рекурсии) не путались, они размещаются там же, в стеке, но доступ к ним идет напрямую. Низкоуровневая работа со стеком довольно хитрая и отличается от компилятора к компилятору, я с этим глубоко не разбирался. Вот область стека доступна программе для записи в произвольную область. Правда, учитывая что она активно используется компилятором, пользоваться этим не стоит. Кроме того, объем стека довольно невелик. По умолчанию в Linux он составляет около 8 МБ.

0

1. Так, получается что когда у нас на этапе линковки у каждой иснтрукции, переменной рассчитывается смещение, относительно базового адреса, затем при запуске exe выделяется память под "это все" при помощи страничной организации памяти - это куча? Что конкретно в ней хранится? Команды для процессора?

2. Исходя из чего назначается область памяти стека для конкретной программы?Откуда этот адрес берется? Во время компиляции?

3. При выходе из ф-ции лок переменные удаляются из стека?

5. Для моей программы что будет в стеке, а что в куче?
6 . Глобальные переменные лежат в куче?

7. При закрытии exe файл удаляется?

8. Правда, что если ты выделил малоком память без фри , то при закрытии exe ОС все равно почистит память. Это плохая практика, но все же?

0

Сообщение от prado777 А стек это не набор регистров, которые очищаются и записываются по воле процессора? Не понятно!

Это вы сейчас регистровое окно описали. Бывает и так, но экзотика. Процессор обычно не умеет работать непосредственно с памятью, сначала ему нужно перенести данные в регистры. Но регистров мало, на все не хватает, поэтому те данные которым места не хватило уезжают в стек. Однако, если отгружать данные в стек не требуется, компилятор может логично заключить "а зачем тогда место под них резервировать?". С другой стороны, у регистров адресов нет. Так что если вот кровь из носа, надо обратиться к переменной по указателю, компилятор вынужден скрепя сердце выдать этой переменной место в стеке.

Сообщение от prado777 1. Считал я смещения так: пользовался для каждой переменной операцией взятия адреса &.

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

0

Сообщение от prado777 организации памяти - это куча?

Нет. Это виртуальная память процесса. Куча формируется поверх нее.

Сообщение от prado777 Исходя из чего назначается область памяти стека для конкретной программы?

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

Сообщение от prado777 Что конкретно в ней хранится?

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

Сообщение от prado777 Команды для процессора?

И они тоже.

Сообщение от prado777 При выходе из ф-ции лок переменные удаляются из стека?

Современные компиляторы используют по возможности регистры для переменных, а не стек. Да и вообще могут все тело функции встроить, так что вопрос требует уточнения. Если рассматривать С++, то локальные у локальных уобъектов заканчивается время жизни при выходе из функции, но нет никакого требования, чтобы компилятор прямо сразу "освобождал" занятые ячейки памяти.

Сообщение от prado777 Глобальные переменные лежат в куче?

Вопрос опять некорректный. Глобальные переменные обычно размещаются в сегменте данных (инициализированных или нет) и "создаются" на момент загрузки приложения. Но это справедливо только для простых типов.

Сообщение от prado777 При закрытии exe файл удаляется?

А самому проверить слабо?

Сообщение от prado777 Правда, что если ты выделил малоком память без фри , то при закрытии exe ОС все равно почистит память.

Да.

0

Сообщение от prado777 1. Так, получается что когда у нас на этапе линковки у каждой иснтрукции, переменной рассчитывается смещение, относительно базового адреса, затем при запуске exe выделяется память под "это все" при помощи страничной организации памяти - это куча? Что конкретно в ней хранится? Команды для процессора?

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

Сообщение от prado777 2. Исходя из чего назначается область памяти стека для конкретной программы?Откуда этот адрес берется? Во время компиляции?

Настройки операционной системы. Их можно изменить и программе будет выдан больший или меньший стек.

Сообщение от prado777 3. При выходе из ф-ции лок переменные удаляются из стека?

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

Сообщение от prado777 5. Для моей программы что будет в стеке, а что в куче?

Все в стеке.
glob_var находится в отдельной области памяти (не в стеке и не в куче). Но тут точно сказать не могу, глубоко не лез. Скорее всего, зависит от компилятора.
loc_var в стеке
dyn_var в куче. Точнее, сам указатель все еще в стеке, но вот указывает на кучу.

Сообщение от prado777 6 . Глобальные переменные лежат в куче?

см. 5.

Сообщение от prado777 7. При закрытии exe файл удаляется?

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

Сообщение от prado777 8. Правда, что если ты выделил малоком память без фри , то при закрытии exe ОС все равно почистит память. Это плохая практика, но все же?

см. 7.

0

На рисунке то, что я выделил красным - это куча?

Регистры переменных, это регистры процессора? Получается при загрузке лок. переменных в память они по возможности загружаются именно в них, а вот если их не хватает - то в стек?

То есть идея такая:
1. Написали программу, у каждой инструкции, переменной есть свое смещение.
2. При запуске exe ОС выделяет память под это: Сегмент стека, сегмент данных и сегмент кодов.
3. В сегменте кодов хранятся инструкции для процессора из нашей программы
4. В сегменте данных хранятся данные (переменные глобальные), но могут и локальные?
5. В стеке хранятся лок. переменные, если при регистров не хватает, указатели на данные из сегмента данных.
6. При вызове ф-ции локальные переменные берутся из стека или из регистров (если их хватило)
7. Затем, дойдя до инстр. RET у этих регистров или ячеек в стеке можно данные перезаписать
8. При вызове следующей ф-ции лок. пер опять пишуться в регистры процессора, при нехватке в стек "на место предыдущих"
9. После закрытия exe, вся память, которая была выделена проге освобождается.

// 10. malloc() realloc() calloc() работают неявно? То есть под объявлением переменной int x=10 скрывается malloc()?
Когда мы хотим динамическое выделение (самое медленное) - скажем при вводе данных с клавиатуры, у нас в куче (сегмент данных см. скрин) по мере ввода выделяется память доп.

Миниатюры

 

0

Как сегмент кода может быть кучей?
malloc() работает явно.

0

Сообщение от prado777 работают неявно?

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

0

А по поводу остального? Значит куча - это сегмент данных

0

Сообщение от prado777 А по поводу остального? Значит куча - это сегмент данных

Нет. На твоей картинке нет кучи

0

Сообщение от prado777 На рисунке то, что я выделил красным - это куча?

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

Сообщение от prado777 То есть идея такая:

Да, примерно такая.
1) Только в exe файле все же секции, а не сегменты.
4) Локальные переменные в стеке, а не в загруженной из exe секции данных.
6) Ну, вернее процессор постоянно жонглирует этими переменными одни выгружая в стек, другие наоборот загружая в регистры.
7) Стандартная практика - при вызове функции состояние регистров сохраняется в стек, при RET возвращается как было.

1

Спасибо!

0

Сообщение от prado777 На рисунке то, что я выделил красным - это куча?

Рисунок скорее похож на DOS.

0