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

[Mark Cave-Ayland]

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.

openbios-cif-nextprop.patch
Description: Text Data