[Openmcl-devel] Clozure CL 1.3-RC1 available
Gary Byers
gb at clozure.com
Mon Feb 16 08:06:18 PST 2009
On Mon, 16 Feb 2009, John Stoneham wrote:
>
>> 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.)
>>
>
> Yes, that's exactly what I get.
Just out of curiousity, if you change that "int $0xd5" to "int $0xc5",
do you still get EXC_BAD_ACCESS with the first code 0xd and the
second (I think) 0x62a ?
The point where you're now dying on Tiger
> Unhandled exception 4 at 0x88adc77, context->regs at #xbffff5cc
- where the "exception 4" is SIGILL - is
0x88adc77: int $0xc5
If all unimplemented 'int $n" instructions raised EXC_BAD_ACCESS,
then that wouldn't have been affected by a change to the EXC_BAD_INSTRUCTION
clause. (So either the assumption that all such 'int $n' instructions
are created equal is invalid, some other clause was changed by mistake,
or there's another, even weirder explanation ...
The last thing that I can think of to ask you to try involves changing
both the EXC_BAD_ACCESS and EXC_BAD_INSTRUCTION clauses, to try to
generate SIGSEGV if the exception is either EXC_BAD_ACCESS or
EXC_BAD_INSTRUCTION, the first code is EXC_I386_GPFLT (= 0xd), and
the program counter is pointing at an 'int $n' instruction.
switch (exception) {
case EXC_BAD_ACCESS:
if (code == EXC_I386_GPFLT) {
signum = SIGILL;
if (*((pc)ts_pc(ts)) == INTN_OPCODE) {
signum = SIGSEGV;
}
} else {
signum = SIGBUS;
}
break;
case EXC_BAD_INSTRUCTION:
signum = SIGILL;
if ((code == EXC_I386_GPFLT) &&
*((pc)ts_pc(ts)) == INTN_OPCODE) {
signum = SIGSEGV;
}
break;
If that works, it was a lucky guess. If not, I probably won't be able
to come up with a better guess until I get that Core Duo iMac back (a
week or two ?) and can see what's going on here.
>
>> 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;
>
> Nope, didn't work, but Tiger and Leopard were different this time. I changed the code above and ran "make" in the lisp-kernel/darwinx8632 directory. It compiled fine without errors on both. On Leopard, when I then ran ccl with the new kernel it behaved the same as it did before: QUIT still threw an error, and rebuilding ccl borked at loading the newly compiled image. The backtraces were the same as they were before, as near as I can tell. The only difference was that ^D didn't cause it to freeze, it just went to a new user prompt. But here's the thing. When I tried it on Tiger, ccl wouldn't even get to the repl. This is what I get (with B, T, and L info):
>
> $ ccl
> Unhandled exception 4 at 0x88adc77, context->regs at #xbffff5cc
> ? for help
> [528] Clozure CL kernel debugger: B
> current thread: tcr = 0x300480, native thread ID = 0x113, interrupts disabled
> [528] Clozure CL kernel debugger: T
> Current Thread Context Record (tcr) = 0x300480
> Control (C) stack area: low = 0xbfe9c000, high = 0xbffff930
> Value (lisp) stack area: low = 0x405000, high = 0x0
> Exception stack pointer = 0x547fec
> [528] Clozure CL kernel debugger: L
> %ebx (arg_z) = #<Anonymous Function #x089B1C3E>
> %esi (arg_y) = #<Anonymous Function #x089B0EBE>
> ------
> %edi (fn) = #<Function (:INTERNAL SAVE-IMAGE) #x088ADC3E>
> ------
> Unhandled exception 10 at 0x2cdc7, context->regs at #xbfffeebc
> Exception occurred while executing foreign code
> at sprint_vector + 12
> ? for help
> [528] Clozure CL kernel debugger:
>
>
>
>
>
>
More information about the Openmcl-devel
mailing list