[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: help with powerpc asm (moving grub_ieee1275_entry_fn initialization
Re: help with powerpc asm (moving grub_ieee1275_entry_fn initialization to crt0.S)
Thu, 17 Jan 2008 12:30:19 -0500
On Thu, 2008-01-17 at 13:17 +0100, Robert Millan wrote:
> On Thu, Jan 17, 2008 at 02:54:33AM -0500, Pavel Roskin wrote:
> > Quoting Robert Millan <address@hidden>:
> > >Here's an incomplete (missing powerpc & sparc) version of the patch that
> > >would sanitize this function call.
> > I don't see why it needs to be done across the board. Maybe you have
> > further simplifications in mind?
> What do you mean? The problem I find is that forcing this to be the third
> parameter of cmain makes it look like cmain has been adapted to accomodate
> for this particular cpu.
Oh, I didn't realize that kern/powerpc/ieee1275/cmain.c is actually used
by the i386-ieee1275 build. That's misleading! Perhaps it should be
moved to kern/ieee1275/
Anyway, Sparc code doesn't use cmain() in any way. It starts
immediately with the function _start() written in C. So you shouldn't
worry about breaking Sparc.
Please feel free to integrate the PowerPC part of my patch into your
patch, as it indeed needs to be committed at once.
> Another option would be to have just one param. This would be the cleanest
> on i386, since the call from OFW already uses -mregparm=1 for the callback
> address, but I don't know about powerpc.
I would prefer that we don't choose global CFLAGS to adjust one
function. There is a "regparm" attribute that can be used on cmain() on
But if you want to keep cmain() shared between architectures, then the
cleanest approach would be to take care of grub_ieee1275_entry_fn before
cmain() is called. It doesn't have to be in assembly. Sparc can still
use its _start function to set grub_ieee1275_entry_fn and then call
> > --- a/kern/powerpc/ieee1275/crt0.S
> > +++ b/kern/powerpc/ieee1275/crt0.S
> > @@ -38,5 +38,9 @@ _start:
> > 2: stwu 2, 4(6) /* We know r2 is already 0 from above. */
> > bdnz 2b
> > + /* Store r5 in grub_ieee1275_entry_fn */
> > + lis 9, address@hidden
> > + stw 5, address@hidden(9)
> I thought you'd also need to remove stuff. Isn't there code above this that
> pushes the 3 parameters onto the stack?
Arguments are transmitted in registers r3, r4 and r5. Nothing is passed
on the stack. r5 has the data we want to be in grub_ieee1275_entry_fn.
The first instruction takes the high 16 bits of the
grub_ieee1275_entry_fn address and put is to register 9. Register 9 is
the favorite choice for memory operations, as it has no special purpose
and doesn't need to be preserved.
The second instruction places the contents of register 5 into an address
pointed to by the register 9 plus the lower 16 bits of the
A 32-bit constant cannot be loaded in one operation, since all PowerPC
commands are 32-bit, and it simply won't fit one command.