[OpenBIOS] [Qemu-ppc] MorphOS 4.x on QEMU

Mark Cave-Ayland mark.cave-ayland at ilande.co.uk
Mon Mar 3 17:19:28 CET 2014


On 03/03/14 15:35, BALATON Zoltan wrote:

> On Mon, 3 Mar 2014, Mark Cave-Ayland wrote:
>> Ah that's why this looks a little strange to me. Can you try with just
>> plain SVN trunk (without Olivier's patch) to make sure that doesn't
>> have an effect too?
>
> Here it is with SVN trunk with only DEBUG_CIF and the memdump length
> changed for nextprop in debug code:
>
>>> nextprop(0xfff517e4, "name", 0x07de7e30) =
> : nextprop ( 7de7e30 7de7e30 fff517e4 )
> fff49f08: >r
> 3 > 7de7e30 20 dump
> 7de7e30 6e 61 6d 65 00 00 00 00 00 00 00 00 00 00 00 00 name............
> 7de7e40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ok
> 3 > resume ok
> ( 7de7e30 7de7e30 fff517e4 )
> fff49f08: >r ( 7de7e30 7de7e30 )
> fff49f0c: dup ( 7de7e30 7de7e30 7de7e30 )
> fff49f10: 0= ( 7de7e30 7de7e30 0 )
> fff49f14: do?branch ( 7de7e30 7de7e30 )
> fff49f28: dup ( 7de7e30 7de7e30 7de7e30 )
> fff49f2c: cstrlen
> 3 > 7de7e30 20 dump
> 7de7e30 6e 61 6d 65 00 00 00 00 00 00 00 00 00 00 00 00 name............
> 7de7e40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ok
> 3 > resume ok
> ( 7de7e30 7de7e30 7de7e30 )
> fff49f2c: cstrlen ( 7de7e30 7de7e30 4 )
> fff49f30: 0
> 3 > 7de7e30 20 dump
> 7de7e30 6e 61 6d 65 00 00 00 00 00 00 00 00 00 00 00 00 name............
> 7de7e40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ok
> 3 > resume ok
> ( 7de7e30 7de7e30 4 )
> fff49f30: 0 ( 7de7e30 7de7e30 4 0 )
> fff49f34: 3 ( 7de7e30 7de7e30 4 0 3 )
> fff49f38: pick ( 7de7e30 7de7e30 4 0 7de7e30 )
> fff49f3c: c!
> 5 > 7de7e30 20 dump
> 7de7e30 6e 61 6d 65 00 00 00 00 00 00 00 00 00 00 00 00 name............
> 7de7e40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ok
> 5 > resume ok
> ( 7de7e30 7de7e30 4 0 7de7e30 )
> fff49f3c: c! ( 7de7e30 7de7e30 4 )
> fff49f40: dup
> 3 > 7de7e30 20 dump

Bingo! This is the problem: "0 3 pick c!" writes a 0 byte into the 
return buffer before calling get-package-property which is why it always 
fails when buf == prev (as prev always becomes an empty string and so 
never matches).

> 7de7e30 00 61 6d 65 00 00 00 00 00 00 00 00 00 00 00 00 .ame............
> 7de7e40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> ok
> 3 > resume ok
> ( 7de7e30 7de7e30 4 )
> fff49f40: dup ( 7de7e30 7de7e30 4 4 )
> fff49f44: do?branch ( 7de7e30 7de7e30 4 )
> fff49f4c: 2dup ( 7de7e30 7de7e30 4 7de7e30 4 )
> fff49f50: r@ ( 7de7e30 7de7e30 4 7de7e30 4 fff517e4 )
> fff49f54: get-package-property ( 7de7e30 7de7e30 4 ffffffff )
> fff49f58: do?branch ( 7de7e30 7de7e30 4 )
> fff49f60: r> ( 7de7e30 7de7e30 4 fff517e4 )
> fff49f64: 2drop ( 7de7e30 7de7e30 )
> fff49f68: 2drop ( Empty )
> fff49f6c: -1 ( ffffffff )
> fff49f70: exit -1
>>> 0x07de7e30 00 61 6d 65 00 00 00 00 00 00 00 00 00 00 00 00
>>> .ame............
>>> 0x07de7e40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> ................
>>> child(0xfff517e4) = 0x00000000
>
>> I wonder if the problem could be caused by the incoming property
>> address and the outgoing property address being the same? It may be
>> that MorphOS relies on an implementation-specific behaviour that means
>> this just happens to work on PPC Open Firmware.
>
> It can be. It looks like that the buffer is cleared before it gets used
> by later code. Do you have any idea how to fix this?

Can you try the attached patch? I think what the "0 3 pick c!" line was 
supposed to do was set an empty string as the fallback return value in 
buf for nextprop.

According to the IEEE1275 specification, return values of -1 and 0 
should return an empty string, so what I've done is move the write of 
the 0 length string into buf to the two points in code just before 
nextprop exits with these return codes.


ATB,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openbios-cif-nextprop.patch
Type: text/x-diff
Size: 660 bytes
Desc: not available
URL: <http://www.openfirmware.info/pipermail/openbios/attachments/20140303/69c2734b/attachment-0001.bin>


More information about the OpenBIOS mailing list