Re: [PATCH 2/2] x86, boot: Optimize the elf header handling.

[ebiederm@xmission.com (Eric W. Biederman)]

"H. Peter Anvin" <hpa@zytor.com> writes:

> On 07/01/2012 12:20 PM, Eric W. Biederman wrote:
>> 
>> Grumble Grumble.
>> 
>> If I force a 2M alignment, poffsets and paddrs align and my previous
>> patches work.  Although I don't expect that to be more than a testing
>> hack.
>> 
>> Meanwhile if I force a 4K max page size for most purposes things look
>> better from a file offset perspective.  But the data segment is now less
>> aligned in the file than it is in memory and my patches don't work.
>> 
>> Sigh.
>> 
>> I feel like I have stumbled into pandoras box.
>> 
>
> Last I looked at this we didn't actually have a general PHDR parser...
> are you running into its limitations?

Sort of.  It was my premise that we should not need a general PHDR
parser, or even a parser at all , especially since a general PHDR parser
is hard to fit into the existing bzImage protocol.  So far emperically
except when dealing with the weird percpu section we don't need a 
general PHDR parser.

There is just enough weirdness that it makes sense to have a
phdr parser that just verifies it doesn't need to do anything.

So I have tracked down part of the crazyness.
CONFIG_RODATA actually uses 2MB alignment, making
-z max_page_size=4096 a bit questionable.

In practice I'm not concerned with a few extra zero's in the file
because giant runs of zeros compress very well.

I am going to play with the percpu section a bit more and see if
I can remove the need for magic to get it's p_offset and p_paddr
to be aligned in the file, as that comes for free with everything
else.

Hmm.  I think I see why the percpu section is problematic.  We have to
specify AT on all of our sections and the usual formula is
".section : AT(.section - LOAD_OFFSET)".  Unfortunately that doesn't
work when we we set the virtual address to zero.

I will play with it a little more and see if I can come up with
something interesting.

Eric