SEH (was GCJ/minGW produced executables and linux/wine)

Thu Mar 13 12:34:00 GMT 2003

> The message http://sources.redhat.com/ml/cygwin/2002-08/msg01598.html 
> seems to contain code to install an SEH handler from gcc-generated 
> code. Is this code still believed correct, and could the GC steal it?
> I'm concerned about the %sp updates in X86 asm code. 
> Can't that confuse compiler-generated offsets for local variables?

I think local variable offsets are generated w.r.t. EBP on x86 (unless
-fomit-frame-pointer is specified, in which case ESP is indeed used), 
so this shouldn't cause a problem as such, but I still share your 
reservations about modifying the stack in the middle of a C function
like this.
I have found that using a local variable (but not a global variable,
don't know why) works as well, as shown below:
----------------------------------- 8< -----------------------------------
 EXCEPTION_REGISTRATION er;
 /* Install handler. */
 er.handler = my_handler;
 asm volatile ("movl %%fs:0, %0" : "=r" (er.prev));
 asm volatile ("movl %0, %%fs:0" : : "r" (&er));
 ...
 /* Remove handler */
 asm volatile ("movl %0, %%fs:0" : : "r" (er.prev));
----------------------------------- 8< -----------------------------------

> If this works, it would allow the GC to deal with the Windows 
> "disappearing root" issue even if it's compiled with gcc.

It does seem to work and I was looking at integrating it into
the GC code. However, this would mean that the removal of the
handler *must* happen irrespective of whether an exception was
actually thrown or not - this means that all the return statements
in GC_mark_some( ) (mark.c) must be consolidated into a single
"point of exit" for the routine (as Dijkstra would have pointed
out anyways ;-)).
> This installs a local handler, which is what the GC needs here. 
> It is different from the NullPointer issue and GC incremental collection, 
> which really want to install a global outermost handler with 
> SetUnhandledExceptionFilter. (Note that if the incremental 
> collector is enabled, it already does so. It should do the right 
> thing if it's the second subsystem to do so. NullPointer handling 
> is hopefully similarly careful about invoking another handler if 
> it's not responsible.)

No, it's not, and this is yet another bug with the
win32_exception_handler( ) method (libjava/win32.cc).
A different concern with the standalone GC (not that OT for this
list) is that "--enable-shared" does not actually build a DLL for
some reason. Anyone know why and how to effect it? Is it a
libtool issue or a configure script issue?
Ranjit.