[OpenBIOS] PPC: QEMU breaks static variables in OpenBIOS

[Alexander Graf]

Am 02.01.2013 um 13:18 schrieb Mark Cave-Ayland <mark.cave-ayland at ilande.co.uk>:

> 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?

I'd be inclined to say it's the latter. But we should ask Ben to make sure.

Ben, is the firmware mapped r/w on Macs?

> 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?

Can't we manually relocate our OpenBIOS code when relocating it?

Imagine we add an extra extraction step to the build process before omitting the final .elf file. In that step we copy the elf relocation info into a special data section that is accessible from within OpenBIOS.

Now when we relocate our .text section down to offset 0x0 we also run a normal elf relocator to move all .data variable access down to offset 0x0.

That way we could still keep globals around, right?


Alex