Перезаписывает ли стек в этом сценарии компоновщика ld сохраненный исполняемый файл?

У меня есть вопрос о поведении скрипта компоновщика, найденного в этом вопросе:

https://stackoverflow.com/a/55193198/2421349

Чтобы сэкономить вам клик, релевантная часть:

OUTPUT_ARCH(riscv)
MEMORY
{
   /* qemu-system-risc64 virt machine */
   RAM (rwx)  : ORIGIN = 0x80000000, LENGTH = 128M 
}
ENTRY(_start)

И в следующем разделе:

 PROVIDE (__executable_start = SEGMENT_START("text-segment", ORIGIN(RAM)));
 . = SEGMENT_START("text-segment", ORIGIN(RAM)) + SIZEOF_HEADERS;
 PROVIDE(__stack_top = ORIGIN(RAM) + LENGTH(RAM));

Мы устанавливаем __executable_start на начало ORIGIN(RAM). Затем мы используем команду ., чтобы переместить место вывода компоновщика на SIZEOF_HEADERS байтов вперед. И, наконец, устанавливаем __stack_top = ORIGIN(RAM) + LENGTH(RAM).

Предполагая, что стек вырастет до ORIGIN(RAM), не будет ли он в конечном итоге перезаписан __executable_start и что бы там ни было SIZEOF_HEADERS, если стек станет достаточно большим?


gnu ld riscv
person kibowki    schedule 07.04.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

person Frant    schedule 08.04.2019