Hi, "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx> writes: > On Tue, 8 Apr 2008, Johannes Weiner wrote: > >> Hi Robert, >> >> "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx> writes: >> >> > On Tue, 8 Apr 2008, Peter Kerpedjiev wrote: >> > >> >> Robert P. J. Day wrote: >> >> > # pmap -d 1 >> >> > 1: init [5] >> >> > Address Kbytes Mode Offset Device Mapping >> >> > ... snip ... >> >> > 00c55000 12 r-x-- 0000000000000000 0fd:00000 libdl-2.7.so >> >> > 00c58000 4 r-x-- 0000000000002000 0fd:00000 libdl-2.7.so >> >> > 00c59000 4 rwx-- 0000000000003000 0fd:00000 libdl-2.7.so >> >> > ... >> >> > >> >> > if you look at the second VMA for that shared lib, its address >> >> > shows that it's 0x3000 higher up in memory, but the Offset >> >> > field shows an offset of only 0x2000. what does that mean? >> >> > thanks. >> >> > >> >> AFAICT, the region from offset 2000 to offset 3000 in libdl-2.7.so >> >> is mapped by both of the first two memory areas. >> >> >> >> I'm not sure why two memory regions would map the same part of a >> >> file with the same permissions. >> > >> > that's what was confusing me, since i read in love's book, p. 256: >> > >> > "Intervals in different memory areas in the same address space cannot >> > overlap." >> > >> > and that sure looks like overlapping to me, but only if you take the >> > "offset" field seriously. >> >> The areas do not overlap, their file mappings do. > > sorry, i still don't understand the explanation. here's the output > for my entire VMA set for "init", and the closer i look, the more > confused i get: > > # pmap -d 1 > 1: init [5] > Address Kbytes Mode Offset Device Mapping > 00110000 4 r-x-- 0000000000110000 000:00000 [ anon ] > 00967000 220 r-x-- 0000000000000000 0fd:00000 libsepol.so.1 > 0099e000 4 rwx-- 0000000000036000 0fd:00000 libsepol.so.1 > 00a3d000 100 r-x-- 0000000000000000 0fd:00000 libselinux.so.1 > 00a56000 8 rwx-- 0000000000018000 0fd:00000 libselinux.so.1 > 00ab0000 108 r-x-- 0000000000000000 0fd:00000 ld-2.7.so > 00acb000 4 r-x-- 000000000001a000 0fd:00000 ld-2.7.so > 00acc000 4 rwx-- 000000000001b000 0fd:00000 ld-2.7.so > 00acf000 1356 r-x-- 0000000000000000 0fd:00000 libc-2.7.so > 00c22000 8 r-x-- 0000000000153000 0fd:00000 libc-2.7.so > 00c24000 4 rwx-- 0000000000155000 0fd:00000 libc-2.7.so > 00c25000 12 rwx-- 0000000000c25000 000:00000 [ anon ] > 00c55000 12 r-x-- 0000000000000000 0fd:00000 libdl-2.7.so > 00c58000 4 r-x-- 0000000000002000 0fd:00000 libdl-2.7.so > 00c59000 4 rwx-- 0000000000003000 0fd:00000 libdl-2.7.so > 08048000 32 r-x-- 0000000000000000 0fd:00000 init > 08050000 4 rw--- 0000000000008000 0fd:00000 init > 08678000 132 rw--- 0000000008678000 000:00000 [ anon ] > b7f41000 8 rw--- 00000000b7f41000 000:00000 [ anon ] > bfafd000 84 rw--- 00000000bffea000 000:00000 [ stack ] > mapped: 2112K writeable/private: 264K shared: 0K > # > > take those two lines corresponding to libsepol.so.1: > > Address Offset > 00967000 220 r-x-- 0000000000000000 0fd:00000 libsepol.so.1 > 0099e000 4 rwx-- 0000000000036000 0fd:00000 libsepol.so.1 > > but 0x967000+0x36000=0x99d000, not 99e000. close, but not quite. > and if you look at some of the other shared libs, you see that same > "off by 0x1000" amount for later VMAs. so why that small difference? > i've checked the source and i still don't see a rationale for that. 220k mapping / 4k pages = 55 pages = 0x96700 to 0x96700+0x37000 which is 0099e000 :) Hannes -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
