[OpenBIOS] PPC: QEMU breaks static variables in OpenBIOS

[Programmingkid]

On Jan 2, 2013, at 7:18 AM, Mark Cave-Ayland wrote:

> Hi all,
> 
> Futher to John's report of next_grab_slot not changing value within the PPC MMU hash_page_32() function, I've done some more experimentation and determined that there is indeed a problem with all OpenBIOS static variables on PPC.
> 
> The issue is that OpenBIOS uses static variables in several places to keep track of various bits of information, and at compile-time these variables are given addresses within the OpenBIOS image itself, e.g.
> 
> (gdb) p &next_grab_slot
> $1 = (int *) 0xfffdd000
> 
> However as John points out, the MemoryRegion associated with OpenBIOS is set to read-only. Single-stepping using gdb shows that while the store to update the value is executed, it is discarded by QEMU and so therefore static variables never change from their initial value.
> 
> Rather amusingly, it seems that setting the variable value via gdb bypasses the MemoryRegion read-only check which made this more interesting to debug.
> 
> I've done a quick hack on QEMU which is to comment out the following line from hw/ppc_oldworld.c in order to make the region read/write again:
> 
> memory_region_set_readonly(bios, true);
> 
> I've confirmed in gdb that this fixes the issue with static variables being able to update their value, and now with the latest round of OS X patches applied, the Darwin kernel boots although panics fairly early on.
> 
> At this point, it seems that we have a decision to make. Is the bug here that the OpenBIOS ROM is marked as read-only for PPC, or OpenBIOS's use of static variables? If it's the latter, I think there is going to have to be a fairly major patch to remove static variables completely from the target image codebase.
> 
> Thoughts?
> 
> Mark.
> 
> -- 
> OpenBIOS                 http://openbios.org/
> Mailinglist:  http://lists.openbios.org/mailman/listinfo
> Free your System - May the Forth be with you


I have noticed that a single register (r9) appears to be used at a base register for all static variables. If we created our own memory region using malloc for static and global variables, and set register r9 to this value, we can make static variables work again. I know it is a hack, but I was able to make static variables work this way. 

Early in the boot process, register r9 is set to 0x7c631a15. This address is what I used to make next_grab_slot work. My guess is the address is a static variable memory region. Register r9 might have been intended to be some kind of base register, but I haven't found any documentation that states this. I do know all static variables in ofmem.c use it for address calculations.