On 03/03/14 13:05, BALATON Zoltan wrote:
On Sun, 2 Mar 2014, Mark Cave-Ayland wrote:
Now the fact that nextprop returns -1 indicates that the following check has failed:
\ verify that prev exists (overkill...) dup if 2dup r@ get-package-property if r> 2drop 2drop -1 exit else 2drop then then
This means that the client requested the next property after "name" but OpenBIOS's get-package-property couldn't find "name" and so returns -1 back to the caller as shown in your trace.
If I remove this check it returns 0 and an empty string. With debug nextprop (and the above check removed + Olivier's patch) I get the following:
(cut)
I hope the above make sense to you and helps finding why it does not work.
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?
The important part is to view the incoming parameters to the function; from your output you show this:
: nextprop ( 7de7e30 7de7e30 fff51908 )
Compare this with the stack diagram in ciface.fs which shows this:
: nextprop ( buf prev phandle -- 1|0|-1 )
According to the IEEE1275 specification, prev should be a NULL-terminated string of the previous property ("name" in this case) while buf should be a buffer into which the next property name is copied.
During debug, you can press "f" to drop to a Forth console and then display memory using the dump command. For example the following will show you what's in the incoming buffer:
7de7e30 20 dump
You can then type "resume" in order to return to the debugger.
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.
ATB,
Mark.