Секция .bss
гарантируется, что все нули при загрузке программы в память. Поэтому любые глобальные данные, которые не инициализируются или инициализируются нулем, помещаются в раздел .bss
. Например:
static int g_myGlobal = 0; // <--- in .bss section
Приятная часть этого вопроса состоит в том, что данные раздела .bss
не обязательно должны быть включены в файл ELF на диске (т. Е. Нет целого региона нули в файле для раздела .bss
). Вместо этого загрузчик знает из заголовков секций, сколько выделяется для секции .bss
, и просто обнуляет его, прежде чем передавать управление вашей программе.
Обратите внимание на вывод readelf
:
[ 3] .data PROGBITS 00000000 000110 000000 00 WA 0 0 4
[ 4] .bss NOBITS 00000000 000110 000000 00 WA 0 0 4
.data
отмечен как PROGBITS
. Это означает, что в файле ELF есть «бит» программных данных, которые загрузчик должен прочитать в памяти для вас. .bss
, с другой стороны, отмечено NOBITS
, что означает, что в файле нет ничего, что должно быть прочитано в память как часть нагрузки.
Пример:
// bss.c
static int g_myGlobal = 0;
int main(int argc, char** argv)
{
return 0;
}
Скомпилируйте его с помощью $ gcc -m32 -Xlinker -Map=bss.map -o bss bss.c
Посмотрите на заголовки разделов с $ readelf -S bss
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
:
[13] .text PROGBITS 080482d0 0002d0 000174 00 AX 0 0 16
:
[24] .data PROGBITS 0804964c 00064c 000004 00 WA 0 0 4
[25] .bss NOBITS 08049650 000650 000008 00 WA 0 0 4
:
Теперь мы ищем нашу переменную в таблице символов: $ readelf -s bss | grep g_myGlobal
37: 08049654 4 OBJECT LOCAL DEFAULT 25 g_myGlobal
Обратите внимание, что g_myGlobal
показано как часть раздела 25. Если мы оглянемся назад в заголовках раздела, мы увидим, что 25 .bss
.
Чтобы ответить на ваш реальный вопрос:
Здесь, в приведенной выше программе, я не имею никаких неинсталлированных данных, но BSS занял 8 байтов. Почему он занимает 8 байтов?
blockquote>Продолжая мой пример, мы ищем любой символ в разделе 25:
$ readelf -s bss | grep 25 9: 0804825c 0 SECTION LOCAL DEFAULT 9 25: 08049650 0 SECTION LOCAL DEFAULT 25 32: 08049650 1 OBJECT LOCAL DEFAULT 25 completed.5745 37: 08049654 4 OBJECT LOCAL DEFAULT 25 g_myGlobal
Третий столбец - это размер. Мы видим наш ожидаемый 4-байтовый
g_myGlobal
, и этот 1-байтовыйcompleted.5745
. Это, вероятно, функция-статическая переменная где-то в инициализации времени выполнения C - помните, что много «вещей» происходит до того, какmain()
когда-либо называется.4 + 1 = 5 байт. Однако, если мы оглянемся на заголовок секции
.bss
, мы увидим, что последний столбецAl
равен 4. Это выравнивание раздела, то есть этот раздел при загрузке всегда будет кратным 4 байтам. Следующий множественный из 5 - 8, поэтому раздел.bss
- 8 байтов.Дополнительно Мы можем посмотреть файл карты, сгенерированный компоновщиком, чтобы увидеть, какие объектные файлы были размещены где в конечном выходе.
.bss 0x0000000008049650 0x8 *(.dynbss) .dynbss 0x0000000000000000 0x0 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib/crt1.o *(.bss .bss.* .gnu.linkonce.b.*) .bss 0x0000000008049650 0x0 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib/crt1.o .bss 0x0000000008049650 0x0 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib/crti.o .bss 0x0000000008049650 0x1 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/32/crtbegin.o .bss 0x0000000008049654 0x4 /tmp/ccKF6q1g.o .bss 0x0000000008049658 0x0 /usr/lib/libc_nonshared.a(elf-init.oS) .bss 0x0000000008049658 0x0 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/32/crtend.o .bss 0x0000000008049658 0x0 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib/crtn.o
Опять же, третий столбец является размером.
Мы видим, что 4 байта
.bss
взяты из/tmp/ccKF6q1g.o
. В этом тривиальном примере мы знаем, что это временный объектный файл из компиляции нашего файла bss.c. Другой 1 байт пришел изcrtbegin.o
, который является частью среды выполнения C.Наконец, поскольку мы знаем, что эта 1 байтовая тайна bss-переменной равна
crtbegin.o
, и она называетсяcompleted.xxxx
, это настоящее имяcompleted
, и это, вероятно, статичность внутри некоторой функции. Глядя наcrtstuff.c
, мы находим виновника: astatic _Bool completed
внутри__do_global_dtors_aux()
.