This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: weird ro mapping generate by ld-linux.so
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: Mathieu Lacage <mathieu dot lacage at gmail dot com>
- Cc: libc-help at sourceware dot org
- Date: Wed, 15 Sep 2010 08:13:34 -0400
- Subject: Re: weird ro mapping generate by ld-linux.so
- References: <AANLkTikUxbanQWYjy-2+Q8_QZa_+SH-pYg=jzWQL4Hg2@mail.gmail.com>
On Tue, Sep 14, 2010 at 8:03 PM, Mathieu Lacage
<mathieu.lacage@gmail.com> wrote:
> 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.
The dynamic loader is a very special case. It is a static application
that is compiled PIC and relocates *portions* of itself into higher
memory.
I haven't looked at your particular question, but in general you need
mappings for:
* RO code
* RO constant data
* RW data
* unreadable/unwritable guard pages
The mapping list you posted doesn't look unreasonable.
Also, because the code is PIC it doesn't have to be placed at the
vaddr of the PT_LOAD, it can be placed anywhere and the relevant
relocations fixed accordingly.
Cheers,
Carlos.