This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: glibc: loading of shared objects with holes wastes address space
- From: Mathias Krause <minipli at googlemail dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, libc-alpha at sourceware dot org, binutils at sourceware dot org
- Date: Tue, 18 Oct 2011 16:15:04 +0200
- Subject: Re: glibc: loading of shared objects with holes wastes address space
- References: <CA+rthh_AeeVmEAotXy3M+ezqK9SOtydw4HBdeVtrgH9OJEPLGg@mail.gmail.com> <20111014164237.4FB7D2C0D3@topped-with-meat.com> <CA+rthh-t9=16zPpR29Xc0=x_nxeozvZYonxchCS+EeprHrPNCA@mail.gmail.com> <mcrvcrm5s89.fsf@coign.corp.google.com>
On Tue, Oct 18, 2011 at 3:44 PM, Ian Lance Taylor <iant@google.com> wrote:
> Mathias Krause <minipli@googlemail.com> writes:
>
>> I see. So the real problem are the holes themselves. If there wouldn't
>> be any gap between two adjacent segments, then there would be no need
>> to stuff them. And honestly, currently those holes are not needed at
>> all. Neither the glibc nor the kernel seem to honor the alignment
>> requirements when searching for a suitable address. So the question
>> is: Why are the sections in the linker script aligned to MAXPAGESIZE
>> instead of PAGESIZE, i.e. aligned to 2 MiB instead of 4 KiB? But it
>> looks like this is more of a question for the binutils folks (CCed).
>
> Because then the executable will still run on some hypothetical future
> kernel that uses larger page sizes.
Are there _any_ plans from Intel/AMD (or rumors, even) to drop the
page size support for 4 KiB pages in a future x86-64 based
architecture? At least, I'm not aware of such a thing. So this can not
really be an argument for choosing 2 MiB for ELF segment alignment.
Mathias