С того, где запускает пространство памяти процесса и где оно заканчивается?

Ну, вы не можете, не совсем ... по крайней мере, не переносным способом. Для стека вы можете сделать что-то вроде:

void* ptr_to_start_of_stack = 0;
int main(int argc, char* argv[])
{
    int item_at_approximately_start_of_stack;
    ptr_to_start_of_stack = &item_at_approximately_start_of_stack;
    // ... 
    // ... do lots of computation
    // ... a  function called here can do something similar, and
    // ... attempt to print out from ptr_to_start_of_stack to its own
    // ... approximate start of stack
    // ... 
    return 0;
}

Что касается попытки взглянуть на диапазон кучи, во многих системах вы можете использовать функцию sbrk () (в частности, sbrk (0) ), чтобы получить указатель на начало кучи (обычно он растет вверх, начиная с конца адресного пространства, тогда как стек обычно растет вниз с начала адресного пространства).

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

Хорошая практика ведения журнала, в дополнение к использованию отладчика, такого как GDB, действительно лучший способ. Попытка отладить вашу программу, глядя на полный дамп памяти, похожа на попытку найти иголку в стоге сена, и поэтому на самом деле это не так полезно, как вы думаете. Более полезно вести журнал там, где логически может быть проблема.

AFAIK, это зависит от ОС, вы должны посмотреть, например, на сегментация памяти.

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

Но, возможно, вы могли бы немного сузить круг вопросов. Если вам действительно нужна просто трассировка стека, ее несложно сгенерировать: Как можно получить трассировку стека в C?

Или, если вы хотите изучить сам стек, легко получить указатель на текущую вершину стека (просто объявите локальную переменную, а затем возьмите ее адрес). Самый простой способ получить нижнюю часть стека - объявить переменную в main, сохранить ее адрес в глобальной переменной и использовать этот адрес позже как «нижний» (это просто, но не совсем «чисто»).

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

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

Предполагая, что вы работаете в основной операционной системе. Вам понадобится помощь операционной системы, чтобы узнать, какие адреса в вашем пространстве виртуальной памяти отображают страницы. Например, в Windows вы должны использовать VirtualQueryEx (). Дамп памяти, который вы получите, может достигать двух гигабайт, маловероятно, что вы быстро обнаружите что-нибудь узнаваемое.

Ваш отладчик уже позволяет вам проверять память по произвольным адресам.

Вы не можете, по крайней мере, не переносно. И нельзя делать много предположений.

Если вы не используете это на CP / M или MS-DOS.

Но с современными системами, где и как расположены ваши данные и код, в общем случае, на самом деле не зависит от вас.

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

Нет никаких гарантий что любой из вашего кода, например, находится даже в непрерывном пространстве. Виртуальная память и загрузчик могут разместить код практически там, где захотят. Также нет никакой гарантии, что ваши данные находятся где-то рядом с вашим кодом. Фактически, нет никакой гарантии, что вы даже сможете ПРОЧИТАТЬ пространство памяти, в котором находится ваш код. (Выполнить, да. Прочитать, может быть, нет.)

На высоком уровне ваша программа разбита на 3 раздела: код, данные и стек. ОС размещает их там, где считает нужным, а менеджер памяти контролирует, что и где вы можете видеть.

Есть множество вещей, которые могут замутить эти воды.

Однако.

Если хочешь.

Вы можете попробовать включить в свой код «маркеры». Например, поместите в начало файла функцию с именем «startHere ()», а затем в конец - функцию с именем «endHere ()». Если вам повезет, для программы с одним файлом у вас будет непрерывный блок кода между указателями функций для «startHere» и «endHere».

То же самое и со статическими данными. Вы можете попробовать ту же концепцию, если она вам вообще интересна.