[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46E9C6E4.5080102@nortel.com>
Date: Thu, 13 Sep 2007 17:25:24 -0600
From: "Chris Friesen" <cfriesen@...tel.com>
To: Jeremy Fitzhardinge <jeremy@...p.org>
CC: linux-kernel@...r.kernel.org, Andi Kleen <ak@...e.de>,
Andrew Morton <akpm@...l.org>,
James Bottomley <James.Bottomley@...eleye.com>,
bapper@...atehaven.org, aaw@...gle.com
Subject: Re: RFC: bug in load_elf_binary?
Jeremy Fitzhardinge wrote:
> Chris Friesen wrote:
>
>>The elf spec says that PT_LOAD segments must be ordered by vaddr. We
>>want to have a segment at a relatively low fixed vaddr. The exact
>>address is not important, except that it's lower than the standard elf
>>headers and so it must be the first segment in the elf file.
>
>
> So you want a zero mapping at a particular address? So the vaddr and
> the memsz are set, but offset and filesz are zero?
I believe that's correct. It's basically the equivalent of BSS, but
used for an emulated OS (the app in question is an emulator).
> Well, you could make the p_offset the same as the first segment with a
> non-zero filesz. That should satisfy the elf loader, though it might
> still confuse things.
Interesting idea. Worth a try.
However, this doesn't address the kernel side of things. Am I correct
in thinking that the kernel is making an invalid assumption that it can
find the load_addr based on the first segment?
> Why can't you create this mapping at runtime?
Our emulated OS wants to put stuff at fixed addresses in this range, so
we're trying to keep the loader from allocating stuff there before our
program gets a chance to start up.
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists