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

Boehm, Hans hans_boehm@hp.com
Thu Mar 13 16:58:00 GMT 2003


> -----Original Message-----
> From: Ranjit Mathew [mailto:rmathew4lists@hotmail.com]
>  
> > 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 ;-)).
> 
Thanks.  It would be great if you could generate a patch for this.

My approach would be slightly different.  I'd define GC_MARK_SOME in
gc_priv.h to be either GC_mark_some_wrapper (win32) or GC_mark_some
(everything else).  That way GC_mark_some_wrapper can do the SEH
stuff and just call a normal unmodified GC_mark_some.  Thus
any ugliness is basically confined to one win32-specific routine.
(I would also move the current non-gcc SEH stuff to the wrapper.
Probably it's best to just have two versions of the wrapper.)
> 
> 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?
> 
The configury stuff changed again in 6.2alpha4, so you should be careful
use that.  Other than that I'm afraid I can't help much here.  I don't
see why it shouldn't.  But building a reliable DLL is probably still
dependent on fixing the SEH issue.  And I don't think the configure files
inthe standalone collector currently know that a multithreaded standalone
win32 GC must be built as a dll.  This has really only been debugged on
Un*x-like systems.

Hans



More information about the Java mailing list