Re: [Qemu-devel] Patch to fix Mac OS X compilation

[Fabrice Bellard <fabrice@bellard.org>]

Jonas Maebe wrote:
> 
> On 19 feb 2005, at 21:00, Jonas Maebe wrote:
> 
>> And again a more improved patch (I think). This one includes a special 
>> case/hack for Mac OS X for __op_gen_label. Now qemu doesn't crash 
>> anymore when trying to boot freedos, but it doesn't show anything 
>> either. I just get a black screen. The same goes for reactos, so I 
>> guess it's some endless loop while emulating the bios or so.
> 
> 
> Here's the semi-final fix (stupid bug in my previous patch). FreeDos can 
> now boot, so long as you do not load any drivers. The reason is that the 
> emulation of the loope instruction goes wrong, and that instruction is 
> used in himem.sys (but does not occur when booting without it). The 
> problem is that this is the assembler code generated by gcc for op_loopzw:
> 
> 0x74370 <op_loopzw>:    mflr    r0
> 0x74374 <op_loopzw+4>:  stw     r0,8(r1)
> 0x74378 <op_loopzw+8>:  stwu    r1,-64(r1)
> 0x7437c <op_loopzw+12>: lwz     r0,48(r27)
> 0x74380 <op_loopzw+16>: rlwinm  r0,r0,3,0,28
> 0x74384 <op_loopzw+20>: lis     r2,12
> 0x74388 <op_loopzw+24>: lwz     r2,-16636(r2)
> 0x7438c <op_loopzw+28>: lwzx    r12,r2,r0
> 0x74390 <op_loopzw+32>: mtctr   r12
> 0x74394 <op_loopzw+36>: bctrl
> 0x74398 <op_loopzw+40>: lhz     r0,6(r27)
> 0x7439c <op_loopzw+44>: cmpwi   cr7,r0,0
> 0x743a0 <op_loopzw+48>: beq-    cr7,0x743b0 <op_loopzw+64>
> 0x743a4 <op_loopzw+52>: andi.   r0,r3,64
> 0x743a8 <op_loopzw+56>: beq-    0x743b0 <op_loopzw+64>
> 0x743ac <op_loopzw+60>: b       0x296eb0 <__op_gen_label1>
> 0x743b0 <op_loopzw+64>: lwz     r0,72(r1)
> 0x743b4 <op_loopzw+68>: addi    r1,r1,64
> 0x743b8 <op_loopzw+72>: mtlr    r0
> 
> 
> At address 0x743ac, the branch to __op_gen_label1 gets patched so it 
> points to the basic block coming after the loopzw. In that case, LR does 
> not get restored (it was destroyed at 0x74394 by the bctrl), so the next 
> blr which gets executed returns to 0x74398. This causes an endless loop, 
> obviously.
> 
> This does not seem to be Mac OS X-specific at all, and should also 
> happen under Linux/ppc I think.

I do not see in your patch any fix for the PARAMn bug. The symptom is:

translate.c:x: error: too many arguments to function `gen_op_xxx'
translate.c:x: warning: initialization from incompatible pointer type

I am using gcc 3.3. The problem is related to the fact that 
'__op_paramN' is no longer exported in the symbol table.

Fabrice.