[Openmcl-devel] Clozure CL 1.3-RC1 available

[Gary Byers]

On Sat, 14 Feb 2009, John Stoneham wrote:

>
>> Let me see if I can create a little program that'd tell us what's
>> different.  OK, if I remembered to attach it, the source should be
>> enclosed.  Compile and run via:
>>
>> shell> cc -m32 -g -o mach32 mach32.c
>> shell> ./mach32
>>
>> When I run it (on a Core 2 Duo), I get:
>>
>> Mach exception: 2 (EXC_BAD_INSTRUCTION) with 2 codes: 0x1 0x0
>>
>> If you get substantially different output, that'd be good (in the
>> sense that it'd tell us what's different and suggest how to handle it.)
>>
>
> I tried it under both Tiger and Leopard just to be sure there were no differences between the systems, and here's the output I get under both:
>
> Mach exception: 2 (EXC_BAD_INSTRUCTION) with 2 codes: 0xd 0x7ea
>
> So I assume this is good news, since it's different from your output, but it's the same under both Tiger and Leopard on my machine.

Thanks.  Does the lisp (mis)behave the same way for you on Leopard as on
Tiger ?



>
> Feel free to throw anything else my way that needs testing.
>

Great, thanks.  There are a couple of things that I'm curious about.

1) In the function 'illegal() in the mach32.c function that I sent out
the other day, there's a commented-out

/*  __asm__ volatile("int $0xd5");  */

If you remove the /* */ comments and recompile, do you get:

Mach exception: 1 (EXC_BAD_ACCESS) with 2 codes: 0xd 0x6aa

(I'd think so.)

2) Does changing the following case clause in
lisp-kernel/x86-exceptions.c (and rebuilding the kernel) fix things
for you, without obviously breaking anything else ?  The clause in
quesion is around line 3190, and the proposed change is to
unconditionally set 'signum' to SIGILL, e.g., to change:

       case EXC_BAD_INSTRUCTION:
         if (code == EXC_I386_GPFLT) {
           signum = SIGSEGV;
         } else {
           signum = SIGILL;
         }
         break;


to:

       case EXC_BAD_INSTRUCTION:
         signum = SIGILL;
         break;

?

[EXC_I386_GPFLT = #xd, which is what you're seeing as the first "code"
value.]

I -think- that that clause was changed as an overly-broad workaround
for some changes that Apple introduced in Leopard and it's pretty
likely to be what's causing the confusion on a Core Duo machine, and
I don't think that changing it would break anything under Leopard
or Tiger on a Core 2 Duo.)

(I actually have a Core Duo iMac; I lent it to someone a few years
ago and haven't been too interested in getting it back.  Since
some of this stuff behaves differently on real 32-bit hardware, I
suppose that I should have been more interested than I have been.)




>
>
>
>
>