Re: weird "gaps" in process's memory map

[Chris Gilbert <chris%dokein.co.uk@localhost>]

Note I've switches mailing list to port-arm as this is not cats specific
8)

On Mon, 23 Dec 2002 00:33:32 -0500
Andrew Brown <atatat%atatdot.net@localhost> wrote:

> two questions, actually.
> 
> (1) pmap shows me this for my shell (tcsh):
> 
> is# pmap -lv
> 00008000-0005b000 r-xp 00000000 10:04 682285     /usr/pkg/bin/tcsh
> 00060000-00065000 rw-p 00050000 10:04 682285     /usr/pkg/bin/tcsh
> 00065000-00092000 rw-p 00000000 00:00 0       [ anon ]
> 00092000-000e2000 rwxp 00000000 00:00 0       [ heap ]
> 20060000-20069000 r-xp 00000000 10:00 9383     /libexec/ld.elf_so
> 20070000-2007a000 rw-p 00000000 00:00 0       [ anon ]
> 2007a000-2007d000 r-xp 00000000 10:00 23     /lib/libtermcap.so.0.5
> 2007d000-20084000 ---p 00003000 10:00 23     /lib/libtermcap.so.0.5
> 20084000-20085000 rw-p 00002000 10:00 23     /lib/libtermcap.so.0.5
> 20085000-2008b000 r-xp 00000000 10:00 15     /lib/libcrypt.so.0.1
> 2008b000-20092000 ---p 00006000 10:00 15     /lib/libcrypt.so.0.1
> 20092000-20093000 rw-p 00005000 10:00 15     /lib/libcrypt.so.0.1
> 20093000-20096000 rw-p 00000000 00:00 0       [ anon ]
> 20096000-2013c000 r-xp 00000000 10:00 13     /lib/libc.so.12.91
> 2013c000-20143000 ---p 000a6000 10:00 13     /lib/libc.so.12.91
> 20143000-20149000 rw-p 000a5000 10:00 13     /lib/libc.so.12.91
> 20149000-20157000 rw-p 00000000 00:00 0       [ anon ]
> ef3fe000-ef9fe000 ---p 00000000 00:00 0       [ stack ]
> ef9fe000-efbe0000 rwxp 00000000 00:00 0       [ stack ]
> efbe0000-efbf0000 rwxp 00000000 00:00 0       [ stack ]
> efbf0000-efbfe000 rwxp 00000000 00:00 0       [ stack ]
> 
> and it stuck me that there are chunks of shared libraries mapped in
> with no read, write, or execute permission.  can anyone tell me why?
> i'm curious...

No idea really, I would expect them to have read permission, or perhaps
they're not so we page them in.  Although I do note that on i386 there
are only 2 sections per shared library.  The interesting thing is that
the unflagged area is 1000 bigger than the following area.

> (2) i note the half gigabyte gap which is MAXDSIZ between the start of
> the data segment and the dynamic linker.  why was one half gigabyte
> chosen?  if we could, would it be better to map the dynamic linker
> (and shared libraries) in directly beneath the stack?

The reason why is probably lost in the mists of time 8)  But I'd guess
that i386 used to use half a gig.

hmmm, something I do note from the pmap output is that the stack is
executable, which surprises me (doesn't actually change anything on arm
though)

In theory we could do libs below the stack, but no-one's implemented
code to do so.  my guess is the placing is fairly generic...

Chris