This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
weird ro mapping generate by ld-linux.so
- From: Mathieu Lacage <mathieu dot lacage at gmail dot com>
- To: libc-help at sourceware dot org
- Date: Wed, 15 Sep 2010 02:03:39 +0200
- Subject: weird ro mapping generate by ld-linux.so
While debugging some bugs of mine, I found out about this memory
mapping generated by the dynamic loader:
30cf200000-30cf284000 r-xp 00000000 08:02 25493849
/lib64/libm-2.9.so
30cf284000-30cf483000 ---p 00084000 08:02 25493849
/lib64/libm-2.9.so
30cf483000-30cf484000 r--p 00083000 08:02 25493849
/lib64/libm-2.9.so
30cf484000-30cf485000 rw-p 00084000 08:02 25493849
/lib64/libm-2.9.so
the first mapping looks nice since readelf -l says:
Type Offset VirtAddr
PhysAddr FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x00000030cf200000
0x00000030cf200000 0x0000000000083618 0x0000000000083618 R E
200000
LOAD 0x0000000000083db8 0x00000030cf483db8
0x00000030cf483db8 0x00000000000002d0 0x0000000000000320 RW
200000
which gives us a base address of 0x30cf200000-0x00000030cf200000 = 0
now, if I look at the second RW PT_LOAD mapping described in the elf
file, its p_vaddr is 0x00000030cf483db8. Since the base address is
zero, I should find the corresponding data in memory at the same
address but the memory mappings generated by the dynamic loader is RO
at this address (the third mapping).
So, there are a couple of options:
- the loader has gone mad (unlikely)
- I don't understand something else
I suspect that it's the latter so, I wonder if someone could enlighten
me so that I understand why this memory mapping is ro and not rw.
Mathieu
--
Mathieu Lacage <mathieu.lacage@gmail.com>