Пример Ubuntu 15.10, Kernel 4.2.0, x86-64, GCC 5.2.1
Достаточно стандартов, давайте посмотрим на реализацию :-)
Локальная переменная
Стандарты: неопределенное поведение.
Реализация: программа выделяет пространство стека и никогда ничего не перемещает по этому адресу, поэтому используется все, что было там ранее.
#include <stdio.h>
int main() {
int i;
printf("%d\n", i);
}
компилировать с помощью:
gcc -O0 -std=c99 a.c
выходы:
0
и декомпилируется с помощью:
objdump -dr a.out
кому:
0000000000400536 <main>:
400536: 55 push %rbp
400537: 48 89 e5 mov %rsp,%rbp
40053a: 48 83 ec 10 sub $0x10,%rsp
40053e: 8b 45 fc mov -0x4(%rbp),%eax
400541: 89 c6 mov %eax,%esi
400543: bf e4 05 40 00 mov $0x4005e4,%edi
400548: b8 00 00 00 00 mov $0x0,%eax
40054d: e8 be fe ff ff callq 400410 <printf@plt>
400552: b8 00 00 00 00 mov $0x0,%eax
400557: c9 leaveq
400558: c3 retq
Из наших знаний о соглашениях о вызовах x86-64:
%rdiэто первый аргумент printf, поэтому строка "%d\n"по адресу0x4005e4
%rsiэто второй аргумент printf, таким образом i.
Это -0x4(%rbp)первая 4-байтовая локальная переменная.
На данный момент rbpядро выделило значение is на первой странице стека, поэтому, чтобы понять это значение, нам нужно заглянуть в код ядра и выяснить, что оно устанавливает.
TODO устанавливает ли ядро этой памяти на что-то, прежде чем повторно использовать ее для других процессов, когда процесс умирает? В противном случае новый процесс сможет читать память других готовых программ, что приводит к утечке данных. См.: Являются ли неинициализированные значения угрозой безопасности?
Затем мы также можем поиграть с нашими собственными модификациями стека и написать такие забавные вещи, как:
#include <assert.h>
int f() {
int i = 13;
return i;
}
int g() {
int i;
return i;
}
int main() {
f();
assert(g() == 13);
}
Локальная переменная в -O3
Анализ реализации на: Что означает <value optimized out> в gdb?
Глобальные переменные
Стандарты: 0
Реализация: .bssраздел.
#include <stdio.h>
int i;
int main() {
printf("%d\n", i);
}
gcc -00 -std=c99 a.c
компилируется в:
0000000000400536 <main>:
400536: 55 push %rbp
400537: 48 89 e5 mov %rsp,%rbp
40053a: 8b 05 04 0b 20 00 mov 0x200b04(%rip),%eax # 601044 <i>
400540: 89 c6 mov %eax,%esi
400542: bf e4 05 40 00 mov $0x4005e4,%edi
400547: b8 00 00 00 00 mov $0x0,%eax
40054c: e8 bf fe ff ff callq 400410 <printf@plt>
400551: b8 00 00 00 00 mov $0x0,%eax
400556: 5d pop %rbp
400557: c3 retq
400558: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1)
40055f: 00
# 601044 <i>говорит, что iнаходится по адресу 0x601044и:
readelf -SW a.out
содержит:
[25] .bss NOBITS 0000000000601040 001040 000008 00 WA 0 0 4
который говорит, что 0x601044находится прямо в середине .bssраздела, который начинается с 0x601040и имеет длину 8 байт.
Затем стандарт ELF гарантирует, что указанный раздел .bssполностью заполнен нулями:
.bssВ этом разделе хранятся неинициализированные данные, которые вносят вклад в образ памяти программы. По определению, система инициализирует данные нулями, когда программа начинает работать. Раздел не занимает файлового пространства, на что указывает тип раздела SHT_NOBITS.
Кроме того, тип SHT_NOBITSэффективен и не занимает места в исполняемом файле:
sh_sizeЭтот член указывает размер раздела в байтах. Если тип SHT_NOBITSраздела не задан , он занимает sh_size
байты в файле. Типовой раздел SHT_NOBITSможет иметь ненулевой размер, но он не занимает места в файле.
Затем ядро Linux должно обнулить эту область памяти при загрузке программы в память при ее запуске.