[Openmcl-devel] OpenMCL for Linux x86-64 available for testing

[Gary Byers]

This is a little harder to diagnose, but there are some clues.
Hmm.  Since you sent your message a few hours ago, I'd guess
that you haven't done a CVS update in the last few minutes ...
Yep.  That's probably the problem.

Another point of view is that the problems were:

(a) the x86-64 ABI requires that C functions that take a variable
number of arguments (like sprintf()) receive the number of arguments
that're passed in floating-point (SSE2) registers as an invisible
argument passed in the low byte of the %rax register.  This value can
range from 0 to 8, and apparently functions that take a variable
number of arguments use the value in the low byte of %rax as an index
into a jump table which dispatches to code that saves the FP arg regs.
Neither the compiler nor #'%FF-CALL was setting %rax to a meaningful
value, so the jump went sailing into the ozone.

(b) the DEFCALLBACK form expanded into code that neglected to
bind a GENSYM which would point to the function's incoming arguments
and return value location because the callback took no arguments,
but referenced that gensym in order to store the return value.
Not only was the code incorrect, but the reference to a GENSYM
as a "undeclared SPECIAL variable" caused some confusion in the
fasl loader.

Thanks.  I think that both of these problems are fixed in CVS now.

I'll probably hold off on building another archive for a day or
two at least.  It should be easy to bootstrap after updating
from CVS, since neither of these problems was very deep.  (That
may not always be the case; it's certainly possible that "deep"
problems remain.)

One way to rebuild things after a CVS update is:

? (rebuild-ccl :full t)

There's a little bit of documentation on REBUILD-CCL in the
file ccl/release-notes.txt;  (REBUILD-CCL :FULL T) deletes
all fasl/.o files and then tries to recompile everything
(including the kernel) and rebuild a heap image.



On Wed, 3 May 2006, James Bielman wrote:

> Gary Byers <gb at clozure.com> writes:
>
>> The problems that James mentioned (and a few that he didn't) all
>> have one root cause: he was using yesterday's version.  Fortunately,
>> a fix is available (in the form of an updated archive and README
>> file.)
>
> Heh! :)
>
> I've gotten further in the CFFI test suite... here's a few more:
>
> Welcome to OpenMCL Version 1.1-pre-060503 (Alpha: LinuxX8664)!
> ? (%stack-block ((p 100))
>    (with-cstrs ((s "%d"))
>      (external-call "sprintf" :address p :address s :int 1000 :int)))
> Unhandled exception 4 at 0x2aaaaafaabdc, context->regs at #x402306b8
> ? for help
> [20520] OpenMCL kernel debugger: b
>
> Framepointer [#x40230E20] in unknown area.
>
> and when compiling callbacks with no arguments:
>
> ;;; callback-1.lisp
> (ccl:defcallback return-int (:int) 100)
>
> Welcome to OpenMCL Version 1.1-pre-060503 (Alpha: LinuxX8664)!
> ? (compile-file "callback-1.lisp")
> ;Compiling "/home/jamesjb/cclhack/callback-1.lisp"...
> ;Compiler warnings for "/home/jamesjb/cclhack/callback-1.lisp" :
> ;   Undeclared free variable #:G1, in RETURN-INT.
> #P"/home/jamesjb/cclhack/callback-1.lx64fsl"
> T
> T
> ? (load "callback-1.lx64fsl")
> ;Loading #P"callback-1.lx64fsl"...
>> Error: bad opcode near position 395 in FASL file "/home/jamesjb/cclhack/callback-1.lx64fsl"
>> While executing: CCL::%BAD-FASL, in process listener(1).
>> Type :POP to abort, :R for a list of available restarts.
>> Type :? for other options.
>
> James
>
>