Результат команды «размер» в Linux и значения текста и EDATA & конец разные

Question

Код

/* test_etext.c */ 

#include <unistd.h> 
#include <stdio.h> 

extern char etext, edata, end; 

int 
main(int argc, char *argv[]) 
{ 
    pid_t pid, ppid; 

    pid = getpid(); 
    ppid = getppid(); 

    printf("%ld\t%ld\t%ld\n", &etext, &edata-&etext, &end-&edata); 

    return 0; 
} 

Затем скомпилировать и запустить его, как этот

gcc -o test_etext test_etext.c 

./test_etext 
4196125 2099507 8 

size ./test_etext 
text  data  bss  dec  hex filename 
1532  592  8 2132  854 ./test_etext 

Вопрос заключается в том, что почему сегмент данные между «& edata- & etext» и «data» различны?

Answer 1

Конечно, они разные! Вы даже читали manpage, man 3 etext?

• etext является первым адресом мимо конца текста (кода),
• edata является первым адресом в конце прошлого инициализированных данных, и
• end является первым адресом в конце прошлого неинициализированные данные (bss)

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

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

Поскольку вы отметили свой вопрос Linux, я лично просто запрошу мнение ядра, прочитав псевдофайл файла /proc/self/statm. Если вам нужна более подробная информация (например, подробная информация о динамически загружаемых библиотеках) или информация, соответствующая выходу команды size, прочитайте /proc/self/smaps или /proc/self/maps псевдофайлы. Все они подробно описаны в man 5 proc.

Для исполняемых файлов ELF - аналогично тому, как size или objdump работают, например, - либо используют существующие утилит, либо существующие библиотеки как минимум.