This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Encoding page size in the ELF header
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Rich Felker <dalias at libc dot org>, Florian Weimer <fweimer at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 28 Sep 2015 11:53:56 -0400
- Subject: Re: Encoding page size in the ELF header
- Authentication-results: sourceware.org; auth=none
- References: <56054662 dot 2010106 at redhat dot com> <20150925195845 dot 3C6312C3B69 at topped-with-meat dot com> <560946D9 dot 6040303 at redhat dot com> <20150928142418 dot GY17773 at brightrain dot aerifal dot cx>
On 09/28/2015 10:24 AM, Rich Felker wrote:
> On Mon, Sep 28, 2015 at 03:55:37PM +0200, Florian Weimer wrote:
>> On 09/25/2015 09:58 PM, Roland McGrath wrote:
>>> p_align indicates the maximum page size that a given binary is built to
>>> handle. What is the precise definition of "expected" that you have in mind?
>>
>> Interesting. I thought it was more of a minimum alignment for that segment.
>
> In a sense it's both. The loader should align to at least this
> alignment (but I don't think that's actually implemented, is it?)
No, it just needs to satisfy the congruence. In the case of the first
PT_LOAD segment usually at p_offset = 0x0, p_vaddr = 0x0, p_align = 0x200000
(x86_64) the congruence "p_offset ~= p_vaddr (mod p_align)" holds for
any value chosen by the kernel. Therefore the kernel need not choose an
alignment equal to p_align.
Subsequently loaded PT_LOAD segments must also satisfy the congruence.
However, in addition to that, they must also be on page-aligned boundaries
in order for the hardware memory protections to apply. If the hardware page
alignment gets larger than p_align, then things get much harder to compute,
if possible.
Note that an object with one PT_LOAD segment is always loadable at any
page alignment. It's possible, but not likely given our current set of
core runtimes (and their sections).
> which makes it a "minimum alignment". The actual "maximum alignment"
> is not p_align but rather:
>
> lcm { (ph[i].p_vaddr-ph[i].p_offset) - (ph[j].p_vaddr-ph[j].p_offset) }
>
> where i,j range over all PT_LOAD headers. With a larger page size you
> cannot simultaneously satisfy the displacement constraints between
> segments.
Right.
In summary:
Roland's right, you could use p_align from the first PT_LOAD segment
to guess the largest possible page alignment supported by the binary.
It's not the truth though, you might support larger if the page alignment
was a multiple of p_align. You might also support much smaller if you
only have one PT_LOAD segment (Rich's lcm equation always being correct).
Does any of this help you solve your problem? :-)
Cheers,
Carlos.