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

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