<roland@xxxxxxxxxx> wrote:
>> Still, this is rather unfortunate as there seems to be no reasonable way
>> to get the ELF loader to reserve memory ranges.
>
> The specified way is to use a PT_LOAD segment with p_flags 0, yielding a
> PROT_NONE mapping that your program can mmap over or munmap after startup.
> If this does not work right, then please file a bug about it.
I don't feel it's a reasonable solution. (But I recognize that others
might think I'm being unreasonable here).
* Linker scripts are too fragile. You can't specify "use the
internal default script, but add this PHDR and this section", so
you need to copy the default, munge it in strange ways to actually
make it work, and then hope that the next glibc/binutils/etc
update doesn't break the script. We've had problems like this
with the linker script on the platform where we're forced to use it
for other reasons.
Case in point, the script you posted a couple of years ago at
<http://lists.gnu.org/archive/html/mit-scheme-devel/2003-11/msg00009.html>
doesn't work any more, but requires moving the "required" PHDR
below the other two PT_LOADs, and adding a FILEHDR option to it.
This seems like a bizarre change, but that's the only way the script
would accept more than two PT_LOADs.
* @nobits PT_LOADed segments don't just reserve the address space,
but also count as allocated space for overcommit purposes (with
the default 0 in /proc/sys/vm/overcommit_memory) unlike memory
allocated with mmap. (Apparently because the protection bits are
discarded, http://bugzilla.kernel.org/show_bug.cgi?id=2255)
We need to reserve large spaces and also run on low-memory
machines.
* Even if both of the above problems were to be fixed in the next
release of FC, we'd still need to find a solution that also works
on older Linux installations.
The other common suggestion of writing/borrowing a ld.so replacement
doesn't seem much more palatable.
--
Juho Snellman
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-devel-list
