[Openmcl-devel] Porting the OpenMCL Compiler

[James Bielman]

Gary Byers <gb at clozure.com> writes:

> Carl Shapiro's been working on a port of CMUCL to Win32 and was
> running into this; I'd suggested using the
> unhandled-exception-filter mechanism, and he said recently that he'd
> solved the problem another way.  I don't know if he's released his
> code yet, but I wouldn't think that his solution would involve
> pc-tables (he basically wanted to ensure that SEH things got unwound
> when lisp did a THROW.)

What Carl is doing in CMUCL/Win32 is creating an SEH handler at the
initial call into Lisp and additional handlers at foreign function
call boundaries.  This is not so bad on x86 because the system
maintains a linked list of exception handlers accessible via the FS
segment register (I think), instead of the PC-table and virtual
unwinding business.

The gory details of how SEH works on RISC CPUs is documented here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcepbguide5/html/wce50conVirtualUnwinding.asp

I'm think the solution to this is hinted at by the following paragraph
from that page:

  Note: All functions that move the stack pointer must have an
  associated PDATA structure for SEH to work. These include any
  function that allocates stack space, calls other functions, saves
  permanent registers, or has an exception handler.

I haven't tested this yet, but I think what I may need to do is use
separate registers for the C and Lisp control stacks.  If the C stack
pointer never moves except at foreign function call boundaries (which
could go through a C function with the correct prolog and PDATA
structure), then the system should be able to find a top-level handler
established before calling into Lisp for the first time.

James