Есть ли возможность отследить выделение памяти в стеке?

Добрый день.
Просто стало любопытно, чтобы отследить выделение памяти в куче достаточно перегрузить оператор new. Например вот так
можно даже перегрузить его глобально, а не внутри класса. При этом о выделении памяти в куче будет сообщаться в консоль, но если я выделю память в стеке то new не вызывается. Можно ли как - то и это отследить, без сторонних утилит ?

0

Сообщение от Anton1978 Можно ли как - то и это отследить, без сторонних утилит ?

Вообще нет.
Максимум можно сделать какой-то stack-аллокатор, на основе, например, нестандартной alloca, в который засунуть логирование. Практического смысла в этом мало, впрочем. Если только как академическое развлечение.

Что за задача у вас, что вам такое понадобилось?

1

Физически нет никакого стэка в CPU. Адреса всех "стэковых" и статических переменных, адреса возврата функций и пр. вычисляются заранее во время компиляции, точнее при запуске без особых ключей - адреса всё время будут разные, вычисляются смещения и после запуска твоей программы (PE-файла под виндой) система автоматом даёт ей память под всё это дело, то есть даёт один раз и только при запуске, т.к. заранее знает сколько нужно памяти, ибо объём статических данных в рантайме не может быть изменён и отследить это "выделение" программно из кода нельзя, т.к. это делает система. Где всё это хранится в реальности - это уже другой вопрос, система сама распихивает эти переменные по регистрам, кешам L1/L2/L3 и общей оперативной памяти накройняк и зависимости от загруженности (других процессов) и объёмов. Отследить это выделение в рантайме нельзя, т.к. количество этих выделений считает сам компилятор.
upd: я не совсем точно всё расписал, на самом деле память под адреса возврата может меняться в рантайме, всё зависит от глубины рекурсии и если перестараешься, схватишь стэковерфлоу. Ещё, если ты используешь экзотику типа _malloca/alloca (см на окончание А), то есть выделяешь память на стэке, тогда размер реально используемой памяти под стэк становится трудно прогнозируемым и ты легко сможешь выскочить за стэк (stackoverflow), но вот именно эти выделения ты сможешь посчитать в рантайме, но зачем? Эти выделения освобождаются при выходе за scope.

1

Сообщение от Anton1978 Добрый день. но еслия в ыделю память в стеке то new не вызывается. Можно ли как - то и это отследить, без сторонних утилит ?

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

Поэтому возникает вопрос: что именно вы хотите отследить? Выделение памяти на входе в функцию? Это несложно: просто следите за положением верхушки стека и все.

1

да собственно нет никакой задачи, просто заполняю пробелы в знаниях.
Вот решил разобраться в аллокаторах. Перегрузка new\delete\malloc\free оказалась не сложной, но вот по ходу пьесы озадачился таким вопросом.

0

Сообщение от Anton1978 заполняю пробелы в знаниях

Будет полезно: https://habr.com/ru/companies/... es/234239/

3

Сообщение от Anton1978 просто заполняю пробелы в знаниях.

Попрограммируйте на ассемблере. Не надо много, просто чтобы понимать как это всё на саммом деле выглядит. Многое станет более понятно.
Потому что все вот эти "динамическая память", "стековая память" ("выделение памяти на стеке"), "статическая память" на языке высокого уровня в самом деле выглядят весьма и весьма абстрактно.
А когда вы посмотрите как это фактически выглядит на процессоре - прям сразу наступит просветление, потому что там оно просто, понятно и очевидно, т.к. непосредственно своими руками всё это трогаешь.

Эх, были времена Z80, когда писание на ассемблере было понятным; ну или хотя бы под DOS.
Сейчас под Windows в этом, к сожалению, слишком много магии, вернее прослоек и много приседаний при старте, тратится слишком много сил на мишуру, не имеющую отношения к сути.

Есть ли среда (ОС) сейчас на IBM PC такая, чтобы программирование на ассемблере выглядело просто и понятно, при этом максимально близко к железу (для понятности) - не знаю.
Может подскажет кто?

1

удивительно, но пару месяцев назад я почитал книгу по NASM, и оказалось что там тоже есть стек

0

Сообщение от Anton1978 и оказалось что там тоже есть стек

Стек - это сущность процессора, если так можно выразиться. Это понятие появляется именно там. В процессоре есть спец. регистры, которые в том числе автоматически изменяются при "стековых" операциях.
В отличии от "динамической памяти", например.

Но тогда вы вообще должны отлично понимать что есть стек. Это тот самый стек процессора и есть.

0

Сообщение от Croessmah Будет полезно: https://habr.com/ru/companies/... es/234239/

Знание данных вещей обязательно пригодится — и если придется отлаживать программу, и если доведется заниматься тонкой подстройкой производительности, да и просто для того, чтобы понимать, что же там, все-таки творится внутри программы.

Вот ни разу не пригодилось.

0

вы хотите сказать что стек с++ и стек процессора это одно и тоже? как-то слабо вериться

0

Сообщение от Anton1978 вы хотите сказать что стек с++ и стек процессора это одно и тоже?

Зависит от того с какой степенью формализма подходить к этому утверждению.

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

В стандарте С++ описано про стековую память, наверняка еще какое-то есть использование термина "стек" (стек вызова процедур, например). Я тут не силен нифига.
Но суть в том, что стандарт С++ описывает некую абстрактную машину.

и в общем случаи наверняка можно найти места, где понятие "стек" с точки зрения стандарта С++ не будет совпадать с понятием "стек" на процессоре x86. Подозреваю, что в стандарте С++ нет как такового самостоятельного понятия "стек", а есть словосочетания только.

Это если придираться и буквоедствовать.

Но "по бытовому" - да, это одно и тоже для С++ и x86 процессора.

Добавлено через 4 минуты
т.е. "переменная на стеке" на x86 платформе будет как раз размещена в том же месте памяти, где и стек процессора, и адрес возврата из процедуры (примерно соответствует "стек вызовов") располагается как раз на стеке процессора, и управляется через процессорные (ассемблерные) команды call и ret

Добавлено через 1 минуту
Там выше ссылку давали ан хабр
там же как раз вот эти все моменты и разжёваны, насколько я понял проглядев по диагонали

Anton1978, Вы её прочитали уже?

0

Anton1978, на самом деле в самом C++ никакого стека нет. В C++ есть классы хранения (storage duration). Это абстракции над способами хранения, выделенные в четыре категории
* Automatic storage duration
* Static storage duration
* Thread local storage duration
* Dynamic storage duration
То, что в обычном бытовом разговоре понимается под "стеком" - это первая категория, объекты с автоматическим классом хранения.

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

0

просто это странно, любая книга по многопоточке утверждает, что у каждого потока есть свой собственный стек и общая для всех куча. Если стек с++ приложения и процессора суть одно и тоже, то сколько же памяти обрабатывает процессор ?
По идее у каждого приложения свой стек это 100500 потоков умножить на 8 мегабайт. Поэтому я всегда был уверен, что на самом деле нет ни стека ни кучи, это все абстракции высоких языков программирования. А NASM просто сделал шаг вперед и создал свою абстракцию.
Или я совсем неверно понимаю распределение памяти ?

Добавлено через 2 минуты
>> Anton1978, Вы её прочитали уже?

почитал, но лучше еще раз почитаю завтра, когда отосплюсь

0

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

Потому что авторы книжек практики и не маятся дурью всё излагать строго в терминах стандарта С++
Т.е. действуют "по-старинке", излагая материал по сути в привязке к конкретной платформе.
Ну просто потому, хотя бы, что подавляющее большинство платформ, с которыми придётся столкнуться в жизни, работают именно в таких терминах, а не в абстрактных терминах стандарта.
И отладчики тоже работают в "физических" терминах, а не абстрактных из стандарта

Добавлено через 2 минуты

Сообщение от Anton1978 По идее у каждого приложения свой стек это 100500 потоков умножить на 8 мегабайт.

Именно так
Вот туда и утилизируются все эти ненормальные гигабайты, требующийся на компьютерах нынче.
Хотя в 48 Кб (включая видеопамять!) умещались не менее увлекательные игры в старые добрые времена

1

Сообщение от Anton1978 Если стек с++ приложения и процессора суть одно и тоже, то сколько же памяти обрабатывает процессор

За это отвечает механизм ОС, называемый "переключение контекста потоков", в процессе его работы как раз сохраняются значения всех регистров, чтобы освободить их для использования другого потока (в том числе и регистра указателя стека). По этой причине у вас начинает безумно тормозить вся система, если вы засунете в поток (особенно на одноядерной системе) бесконечный цикл без паузы: переключение контекста начнет происходить слишком часто (а это, как вы уже поняли весьма затратная операция).

1

Сообщение от Anton1978 Если стек с++ приложения и процессора суть одно и тоже, то сколько же памяти обрабатывает процессор ?

Потоки создает не процессор, потоки создает операционная система, она же (при переключении ядра процессора между разными потоками) сохраняет текущее состояние процессора, "переключает" на новый стек, стек другого потока (просто заполняет регистры процессора данными того, другого потока), после чего пускает процессор выполнять код.
С точки зрения процессора он просто тупо выполняет и выполняет последовательность команд, но ОС переключает его между разными последовательностями при переключении потоков, "подсовывая" команды из разных областей памяти , где хранится код разных потоков (Делает это код ОС путём изменения значения регистра адреса команд процессора)

1