RE: WIN-31: boehm-gc don't do SEH in GCC

["Boehm, Hans" <hans_boehm at hp dot com>]

I assume gcc just doesn't support structured exception handling on Windows?
Fundamentally that seems fine, except that some of the Windows APIs rely on
it.

In particular, I think this is a reliability issue for the GC code.  The
collector uses VirtualQuery to identify locations that it should scan for
statically allocated pointer variables.  Some variants of Windows are known
to asynchronoulsy unmap some of those while the collector isn't looking.
(And the Windows documentation basically says that this may happen.  As I
recall it specifically recommends the technique Iused here.)  I don't really
know of a way to protect the collector against generating exceptions as a
result of trying to access these "disappearing" roots.  Unless you know
something about this that I don't, it seems to me we have to find some way
to catch them and recover.  Or we have to switch to a model where we
explicitly register static roots.

Hans

> -----Original Message-----
> From: Adam Megacz [mailto:patches@lists.megacz.com]
> Sent: Wednesday, March 06, 2002 5:05 PM
> To: java-patches@gcc.gnu.org
> Subject: WIN-31: boehm-gc don't do SEH in GCC
> 
> 
> 
> Ok to commit?
> 
>   - a
> 
> 2002-03-06  Adam Megacz  <adam@xwt.org>
> 
>         * win32_threads.c (thread_start): Don't attempt SEH with gcc.
>         * mark.c (GC_mark_some): Don't attempt SEH with gcc.
> 
> Index: win32_threads.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/boehm-gc/win32_threads.c,v
> retrieving revision 1.9
> diff -u -r1.9 win32_threads.c
> --- win32_threads.c	2002/02/25 04:04:43	1.9
> +++ win32_threads.c	2002/03/07 01:09:44
> @@ -447,16 +447,22 @@
>      /* Clear the thread entry even if we exit with an 
> exception.	*/
>      /* This is probably pointless, since an uncaught 
> exception is	*/
>      /* supposed to result in the process being killed.	
> 		*/
> +#ifndef __GNUC__
>      __try {
> +#endif /* __GNUC__ */
>  	ret = args.start (args.param);
> +#ifndef __GNUC__
>      } __finally {
> +#endif /* __GNUC__ */
>  	LOCK();
>  	args.entry->stack = 0;
>  	args.entry->in_use = FALSE;
>  	      /* cast away volatile qualifier */
>  	BZERO((void *) &args.entry->context, sizeof(CONTEXT));
>  	UNLOCK();
> +#ifndef __GNUC__
>      }
> +#endif /* __GNUC__ */
>  
>      return ret;
>  }
> Index: mark.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/boehm-gc/mark.c,v
> retrieving revision 1.12
> diff -u -r1.12 mark.c
> --- mark.c	2002/02/12 04:37:53	1.12
> +++ mark.c	2002/03/07 01:09:44
> @@ -264,7 +264,7 @@
>  GC_bool GC_mark_some(cold_gc_frame)
>  ptr_t cold_gc_frame;
>  {
> -#ifdef MSWIN32
> +#if defined(MSWIN32) && !defined(__GNUC__)
>    /* Windows 98 appears to asynchronously create and remove 
> writable	*/
>    /* memory mappings, for reasons we haven't yet understood. 
>  Since	*/
>    /* we look for writable regions to determine the root set, 
> we may	*/
> @@ -274,7 +274,7 @@
>    /* Note that this code should never generate an 
> incremental GC write	*/
>    /* fault.							
> 	*/
>    __try {
> -#endif
> +#endif /* defined(MSWIN32) && !defined(__GNUC__) */
>      switch(GC_mark_state) {
>      	case MS_NONE:
>      	    return(FALSE);
> @@ -395,7 +395,7 @@
>      	    ABORT("GC_mark_some: bad state");
>      	    return(FALSE);
>      }
> -#ifdef MSWIN32
> +#if defined(MSWIN32) && !defined(__GNUC__)
>    } __except (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION ?
>  	    EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH) {
>  #   ifdef CONDPRINT
> @@ -410,7 +410,7 @@
>      scan_ptr = 0;
>      return FALSE;
>    }
> -#endif /* MSWIN32 */
> +#endif /* defined(MSWIN32) && !defined(__GNUC__) */
>  }
>  
>  
>