On Sun, Aug 22, 2010 at 09:18:43PM +0300, Avi Kivity wrote:
On 08/22/2010 08:40 PM, Kevin O'Connor wrote:
On Sun, Aug 22, 2010 at 08:07:53PM +0300, Avi Kivity wrote:
I see that ld has some support for overlays, perhaps we can use that?
The overlay support is basically just another way of manipulating the run-time addresses of the code at build time. Unfortunately, it can only specify static addresses, and I don't think there is any safe static address that can be used (outside of 0xc0000-0xfffff).
Is that not useful? We can push, say the IDE and virtio drivers to overlay the same address range in the e/f segments, and have the stubs pull them in as necessary.
I guess you're describing a way of swapping parts of the BIOS in. It could be made to work, but seems very complicated.
Relocating the code isn't that bad. It should just be a matter of storing which parts of the code rely on a fixed address, and then updating those addresses at runtime. Something like:
// Info provided by build extern u32 Relocs; extern u32 NumRelocs; extern void *OrigCodeAddr; extern u32 CodeSize;
// Relocation code. memcpy(newaddr, OrigCodeAddr, CodeSize); for (i=0; i<NumRelocs; i++) *(u32*)(newaddr + Relocs[i]) += (newaddr - OrigCodeAddr);
If the code can be relocated, it should be okay to put it at the top of high memory. Relocating should be more transparent than "swapping" to developers, as it wouldn't impose any limits on what can code can call other code.