Назначение стека потоку

Во-первых, при построении простой тестовой программы, которая запускает один поток, мы можем увидеть syscalls, которые она использовала для создания нового потока. Вот простая тестовая программа:

#include <pthread.h>
#include <stdio.h>

void *test(void *x) { }

int main() {
        pthread_t thr;
        printf("start\n");
        pthread_create(&thr, NULL, test, NULL);
        pthread_join(thr, NULL);
        printf("end\n");
        return 0;
}

И соответствующая часть его вывода strace:

write(1, "start\n", 6start
)                  = 6
mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0xf6e32000
brk(0)                                  = 0x8915000
brk(0x8936000)                          = 0x8936000
mprotect(0xf6e32000, 4096, PROT_NONE)   = 0
clone(child_stack=0xf7632494, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xf7632bd8, {entry_number:12, base_addr:0xf7632b70, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xf7632bd8) = 9181
futex(0xf7632bd8, FUTEX_WAIT, 9181, NULL) = -1 EAGAIN (Resource temporarily unavailable)
write(1, "end\n", 4end
)                    = 4
exit_group(0)                           = ?

Мы видим, что он получает стек из mmap с PROT_READ|PROT_WRITE защитой и MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK флагами. Затем он защищает первую (т. е. самую нижнюю) страницу стека, чтобы обнаружить переполнение стека. Остальные звонки не имеют отношения к обсуждению на конференции. рука.

Итак, как же тогда mmap распределяет стек? Ну, давайте начнем с mmap_pgoff в ядре Linux; точка входа для современного mmap2 syscall. Он делегирует на do_mmap_pgoff после того, как снял несколько замков. Это потом зовет get_unmapped_area чтобы найти соответствующий диапазон несопоставленных страниц.

К сожалению, это затем вызывает указатель функции, определенный в vma-это, вероятно, так, что 32-разрядные и 64-разрядные процессы могут иметь различные представления о том, какие адреса можно нанести на карту. В случае x86 это определяется в arch_pick_mmap_layout, который переключается в зависимости от того, использует ли он 32-разрядную или 64-разрядную архитектуру для этого процесса.

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

Так что, как вы можете видеть, обычно он назначает стеки по возрастанию (для x86; x86-64 использует arch_get_unmapped_area_topdown и, вероятно, назначит их по убыванию). Тем не менее, он также хранит кэш, где начать поиск, поэтому он может оставить пробелы в зависимости от того, когда освобождаются участки. В частности, когда область mmaped освобождается, она может обновить кэш свободного поиска адресов, так что вы можете увидеть там также неупорядоченные распределения.

Тем не менее, это все детали реализации. Не полагайтесь ни на что из этого в своей программе. Просто возьмите то, что адресует mmap руки и будьте счастливы:)