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.