1

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?

Christopher Francisco
  • 15,672
  • 28
  • 94
  • 206

1 Answers1

2

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).

rslemos
  • 2,454
  • 22
  • 32
  • are the 2 segments, where the inode column is 0, part of myprogram? if so, what do they represent? – Christopher Francisco Jul 08 '14 at 03:52
  • Perhaps `mmaped()` memory by some library initializer. Can also be The Heap. – rslemos Jul 08 '14 at 03:53
  • Humm... on my system the heap is indicated with "[heap]". That leaves me only with anonymous `mmap()` memory. – rslemos Jul 08 '14 at 03:58
  • I understand, thank you very much. It's for a project which they just left the practice, but not theory at all so I was totally lost – Christopher Francisco Jul 08 '14 at 04:00
  • 1
    @ChristopherFrancisco I think the 0 inodes incidate the non-initialized heap data, since they have no location within the file. The segment indicated as being at offset 0x1000 is perhaps the initialized heap data. You could try displaying the contents of the executable at that point with `od -j 4096 -N 48 -Ax -i program` – ooga Jul 08 '14 at 04:04
  • Btw, the function `show_map()` is declared as `static`, is that the reason the second segment is `r` only? – Christopher Francisco Jul 08 '14 at 04:04
  • I'll throw a wild guess: perhaps these anonymous chunks are mmaped by the loader to fit plt and got tables. I ran `cat /proc/self/maps` under strace and two chunks got mmapped even before libc was loaded, so the loader itself is reserving those chunks. – rslemos Jul 08 '14 at 04:05
  • I thought that "r" only segment was for ".rodata" (read-only data, like consts and strings). – rslemos Jul 08 '14 at 04:08
  • A function being `static` means: i) it will not be available for linking (i.e., is not exported); and ii) it may be optimized out if no other function calls it within the same source. – rslemos Jul 08 '14 at 04:09
  • Hmm the only thing similar to a string is a `printf("\n------");` in the program, could that be it? – Christopher Francisco Jul 08 '14 at 04:10
  • @ChristopherFrancisco That's exactly the kind of data that goes into ".rodata" section. Try `objdump -s **` and look for ".rodata" section. There should be all your strings (and other consts, like array initializers) – rslemos Jul 08 '14 at 04:13