Tarl Neustaedter wrote:
It looks like the forth code is simply wrong. The first few tokens in forth/system/ciface.fs:seek are clearly expecting arguments in the wrong order ("swap rot dup ihandle>phandle" expects ihandle in the 3rd argument rather than 1st). The question is what in OpenBios depends on that misbehaviour, and there I am very much out of my depth.
Nothing _in_ OpenBIOS should be using client interface methods. If it did, we should fix that as we proceed.
With such a bug I wonder, however, how we could ever boot a client.
Attached patch should improve the behavior. It's untested though, possibly additional cleanup is needed after call-method...
reverse order of parameters for 6.3.2.3 Device I/O client interface functions.
Signed-off-by: Stefan Reinauer stepan@coresystems.de
Index: forth/system/ciface.fs =================================================================== --- forth/system/ciface.fs (revision 613) +++ forth/system/ciface.fs (working copy) @@ -212,21 +212,16 @@ close-dev ;
-: read ( ihandle addr len -- actual ) - rot dup ihandle>phandle " read" rot find-method - if swap call-package else 3drop -1 then +: read ( len addr ihandle -- actual ) + rot swap " read" call-method ;
-: write ( ihandle addr len -- actual ) - rot dup ihandle>phandle " write" rot find-method - if swap call-package else 3drop -1 then +: write ( len addr ihandle -- actual ) + rot swap " write" call-method ;
-: seek ( ihandle pos_hi pos_lo -- status ) - \ package methods uses ( pos_lo pos_hi -- status ) - swap - rot dup ihandle>phandle " seek" rot find-method - if swap call-package else 3drop -1 then +: seek ( pos_lo pos_hi ihandle -- status ) + " seek" call-method ;
@@ -261,7 +256,7 @@
: interpret ( xxx cmdstring -- ??? catch-reult ) dup cstrlen - \ ." INTERPRETE: --- " 2dup type + \ ." INTERPRET: --- " 2dup type ['] evaluate catch dup if \ this is not necessary an error... ." interpret: exception " dup . ." caught" cr