This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc: loading of shared objects with holes wastes address space

On Tue, Oct 18, 2011 at 7:04 PM, Roland McGrath <> 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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]