Subject: Re: Alocation of OF_buf?
To: Andrew Cagney <firstname.lastname@example.org>
From: Andrew Cagney <email@example.com>
Date: 10/26/2001 12:31:28
> I'm trying to understand the logic behind the allocation of the OF_buf. As best I can tell, ofppc/locore.S and macppc/locore.S both just grab some space sitting at the end of the .data segment.
> Unfortunatly PSIM exactly allocates the data/bss segment and the OF_buf ends up with an unmapped VM address. I get the feeling that the code is assuming that the stack will be placed directly after .bss.
It was pointed out that some systems map things 1:1 at startup. The
following may also be relevant:
locore.S goes through the sequence:
this saves the open firmware's VM state
(the program is being started in virtual mode)
find the address of &end
OF_buf = (end + 0xfff) & ~0xfff
i.e. page aligned just beyond &end
That puts the buffer on the page just beyond text/data. Since PSIM
doesn't map things 1:1, that page won't be in the OF's address space.
Does anyone know what the Mac's OF does to the VM when it passes control
to the kernel?
Assuming this is declared a ``bug'', I'm wondering why space for OF_buf
isn't simply included in the kernel's .bss like was done for other bits
of the OF <-> kernel interface code.