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.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
