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 <[EMAIL PROTECTED]>: > > > > >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 i386 architecture. 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 cmain(). > > --- 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, [EMAIL PROTECTED] > > + stw 5, [EMAIL PROTECTED](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 grub_ieee1275_entry_fn address. 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. -- Regards, Pavel Roskin _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
