This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc: loading of shared objects with holes wastes address space
On Tue, Oct 18, 2011 at 7:04 PM, Roland McGrath <roland@hack.frob.com> wrote:
>> It does, but creating a mapping that covers the whole file and even
>> more beyond EOF with the flags of the first segment is not nice. It
>> makes parts of the shared object executable that should not be. For
>> only a short amount of time, though. Nevertheless, nothing one would
>> expect from happening.
>
> I suppose that is a valid point. ?Nevertheless, for ET_DYN objects, a
> single initial mapping that is of the whole size is necessary to reserve
> the address space required. ?That mapping needs to be from the file because
> some kernels like to choose memory regions to use differently for file
> mappings than for anonymous ones.
I understood this requirement. Making the initial mapping cover the
whole address range is not a problem per se, but mapping it as
PROT_EXEC is -- a minor one, though.
> In the case where there is a hole that needs to be PROT_NONE, it could
> achieve the same end result with the same number of system calls in a
> different way. ?That is, do the initial mapping with PROT_NONE and then use
> mprotect to set the first segment to its final protections (i.e. usually
> PROT_READ|PROT_EXEC). ?That would not have the window of extra
> executability that you are concerned about.
That would be a solution for this problem, indeed. Mind implementing
it yourself?
Regards,
Mathias