This is the mail archive of the
mailing list for the Java project.
SEH (was GCJ/minGW produced executables and linux/wine)
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- To: "'Ranjit Mathew'" <rmathew at hotmail dot com>, java at gcc dot gnu dot org
- Cc: "'gshapiro at his dot com'" <gshapiro at his dot com>
- Date: Wed, 5 Mar 2003 10:25:02 -0800
- Subject: SEH (was GCJ/minGW produced executables and linux/wine)
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?
If this works, it would allow the GC to deal with the Windows "disappearing root" issue even if it's compiled with gcc.
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.)
> -----Original Message-----
> From: Ranjit Mathew [mailto:rmathew4lists at hotmail dot com]
> Sent: Wednesday, March 05, 2003 1:35 AM
> To: java at gcc dot gnu dot org
> Subject: Re: GCJ/minGW produced executables and linux/wine
> > Andrew> Well, from a very rough reading it looks to me like
> SEH should
> > Andrew> be able to do what Win32 gcj needs.
> > I thought there was no way to access SEH from gcc, and that this was
> > one of the longstanding gcc/Windows interoperability problems.
> SEH is an OS-provided facility and "__try/__except" is merely
> (quite desirable) syntactic sugar coating of these by the MSVC
> (and compliant) compilers - see the "Compiler-level SEH" section in:
> In fact, had the following patch by Aldy Hernandez for adding
> "__try/__finally" support to GCC been accepted, it would have caused
> a *major* confusion for people already used to Win32 SEH:
> As I remark in a separate post, it *should* be possible to
> achieve what we need using SEH.