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

[Gary Byers]

I was able to get to this and found several problems in defcallback,
compiled %FF-CALL, and the %FF-CALL function.

Among those problems was the fact that compiled %FF-CALL incremented
the stack location in which the 9th-nth FP args were passed twice
for each argument.  This caused a return address on the foreign
stack to get overwritten with a float, but apparently didn't clobber
the nearby frame pointer, so it looks like the thread on which this
happened (probably the listener) tried to return to a float as it
was exiting.  (There were a few other bugs whose details are in the
ChangeLog, but trying to return to a float seems like a notably
unusual symptom.)

This seems to now be fixed in CVS, and FF-CALLS and callbacks 
involving large numbers (26) of integers and floats all seem to
get the right answer without obviously clobbbering anything.
(There's an outstanding PPC bug involving callbacks with more
than 13 FP args, but that's another story.)

On Thu, 4 May 2006, Gary Byers wrote:

> Even better for the "we're trying to return to a float" hypothesis;
> that address is the point where a thread returns from running lisp
> code and goes back to the pthread startup code that'll kill it off.
>
> I think that I know what to look at; thanks.
>
> On Thu, 4 May 2006, James Bielman wrote:
>
>> Gary Byers <gb at clozure.com> writes:
>>
>>> If you get a chance, please try:
>>>
>>> gdb /path/to/lx86cl64
>>> (gdb) x/i 0x410561
>>>
>>> where 0x410561 is the address where the crash is reported.
>>
>> (gdb) x/i 0x410561
>> 0x410561 <toplevel_loop+137>:   retq
>>
>> James
>>
>>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>