[Openmcl-devel] CCL trunk on Linux ARM / Ubuntu - Unhandled exception 4

Rainer Joswig joswig at lisp.de
Sat May 31 13:01:48 PDT 2014


Started the new image. Now without problems.

Many thanks!

Regards,

Rainer


Am 31.05.2014 um 21:52 schrieb Gary Byers <gb at clozure.com>:

> OK.  r16100 in the trunk contains a small compiler change to avoid use
> of the problematic instruction and a new armcl.image built with this
> change in effect.  Please let me know if this fixes the problem.
> 
> 
> On Sat, 31 May 2014, Gary Byers wrote:
> 
>> In both cases that I've looked at, the allegedly illegal instruction is
>> of the form:
>> 
>>       str sp,[sp, #-16]!
>> 
>> That's intended to store the current value of the stack pointer -16 bytes from
>> that current value and update the sp register so that it points to the word
>> that was just stored.  That's used to create a small frame on the stack where
>> unboxed values can be stored and that's a new feature; I was going to say
>> that it's a perfectly valid and harmless instruction, but after R'ing TFM
>> I note that this form of this instruction is described as having unpredictable
>> behavior, and that seems to be exactly what you're seeing.
>> 
>> In other words, this is definitely a CCL bug (which is a lot better than some
>> of the other possibilites would have been.)
>> 
>> 
>> On Sat, 31 May 2014, Rainer Joswig wrote:
>> 
>>> Am 31.05.2014 um 11:35 schrieb Gary Byers <gb at clozure.com>:
>>>> I don't have a good guess, but another bad guess is that this is an instruction
>>>> cache problem.  (For anyone who cares: most RISC machines have separate instruction
>>>> and data caches; the X86 has a unified cache.  When machine code is written to
>>>> memory, it's often actually only written to the data cache and isn't actually
>>>> loaded into the instuction cache unless special steps are taken.  A typical
>>>> symptom of failing to take those steps is that the processor executes code
>>>> "that isn't there" (what the processor actually executes isn't consistent
>>>> with what appears to be in memory.)
>>> Gary, here is another data point.
>>> The ODROID XU has a big.LITTLE CPU.
>>> Exynos5 Octa Cortex?-A15 1.6Ghz quad core and Cortex?-A7 quad core CPUs
>>> Exynos 5410
>>> It seems that it runs fine on the big cores and crashes on the LITTLE cores.
>>> If I start CCL when the CPU is using the big cores, CCL runs fine.
>>> If I start CCL when the CPU is using the little cores, CCL crashes.
>>> If I start CCL when the CPU is using the big cores, CCL runs fine. Switching back to the little ones, then crashes the crunning CCL.
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://lists.clozure.com/mailman/listinfo/openmcl-devel
>> 
>> 




More information about the Openmcl-devel mailing list