Reputation: 16278
I get the theory about the columns address, permissions, offset, device, etc... But I haven't found the relationship of each segment to the program itself, for example consider the following map:
08048000-08049000 r-xp 00000000 08:01 132351 /home/myuser/myprogram
08049000-0804a000 r--p 00000000 08:01 132351 /home/myuser/myprogram
0804a000-0804b000 rw-p 00001000 08:01 132351 /home/myuser/myprogram
0804b000-0804e000 rw-p 00000000 00:00 0
b751f000-b7520000 rw-p 00000000 00:00 0
..... more mapping starting with libc mapping
For the program:
int global_noini; /* non-array non-initialized */
int global_ini=666; /* non-array initialized */
int vec_global_noini[4000]; /* array non-initialized */
/* array_initialized */
int vec_global_ini[]={31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
int main(int argc, char **argv) {
int local; /* non-array local variable */
int vec_local[2500]; /* array local variable */
/* This function prints the map above */
show_map();
return 0;
}
What I need to know is in what segment are what variables and why.
So far, I believe (correct me if I'm wrong) that the code itself is in the first segment because it has a x permission (execute). But what about the non-inited, inited, global and local variables, in which segment do they belong and why?
Upvotes: 1
Views: 482
Reputation: 2730
Local variables are nowhere. Yet. They'll be on stack when function frame becomes active.
Const data surely is somewhere flagged as "r" but not "w" nor "x".
Initialized data is somehwere flagged as "rw" but not "x". Non-initialized data perhaps is there too: in fact, .data (initialized) and .bss (non-initialized) are the same, except that .bss does not occupy space in the executable image (it is initialized to zero by the loader).
Upvotes: 2