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

i'm not on that list...i guess i'll have to join.  :)

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

no, that's the offset into the file being mapped.  i gave the "linux
style" map output, but here's the (truncated) "all" output:

% pmap -a | cut -c-76
Start    End         Size  Offset   rwxpc  RWX  I/W/A Dev     Inode - File
...
2007a000-2007cfff      12k 00000000 r-xp+ (rwx) 1/0/0 16:00      23 - /lib/l
2007d000-20083fff      28k 00003000 ---p+ (rwx) 1/0/0 16:00      23 - /lib/l
20084000-20084fff       4k 00002000 rw-p- (rwx) 1/0/0 16:00      23 - /lib/l
20085000-2008afff      24k 00000000 r-xp+ (rwx) 1/0/0 16:00      15 - /lib/l
2008b000-20091fff      28k 00006000 ---p+ (rwx) 1/0/0 16:00      15 - /lib/l
20092000-20092fff       4k 00005000 rw-p- (rwx) 1/0/0 16:00      15 - /lib/l
20093000-20095fff      12k 00000000 rw-p+ (rwx) 1/0/0 00:00       0 -   [ an
20096000-2013bfff     664k 00000000 r-xp+ (rwx) 1/0/0 16:00      13 - /lib/l
2013c000-20142fff      28k 000a6000 ---p+ (rwx) 1/0/0 16:00      13 - /lib/l
20143000-20148fff      24k 000a5000 rw-p- (rwx) 1/0/0 16:00      13 - /lib/l
...

the zero permission chunks are all 28k and at one page further into
the shared object than the following chunk.

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

uh, let's see. it's one gig now (since 97), was a quarter before than
(since late 93), and was 32 megs for the eight months prior to that.
close enough, though.

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

that's the same on my i386, sparc, and alpha.  i thnk all the ports
have that "feature" (thought it may be going away soon).

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

i've got some.  that's the reason that i've been adding forward merge
to new allocations and backwards extend to amaps.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."