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

["Ranjit Mathew" <rmathew4lists at hotmail dot com>]

> 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.