[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <46EAD121.5080804@goop.org>
Date: Fri, 14 Sep 2007 11:21:21 -0700
From: Jeremy Fitzhardinge <jeremy@...p.org>
To: Chris Friesen <cfriesen@...tel.com>
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?
Chris Friesen wrote:
> 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).
Right.
>> 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?
God, that code is such a tangle. I'm not sure why it particularly cares
about the offset, though perhaps its making sure that (offset %
pagesize) == (vaddr % pagesize), which only matters for filesz>0.
It's not too surprising it falls over with more unconventional ELF files.
>> 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.
Hm, you might want to have a look at how valgrind gets itself started.
J
-
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