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

[Roland McGrath <roland at hack dot frob dot com>]

> 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.

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.


Thanks,
Roland