[Gc] workaround for C++ exceptions problem

Boehm, Hans hans.boehm at hp.com
Tue Jan 24 14:51:33 PST 2006


Thanks.

My concern is that this is incredibly brittle.  I've gotten into trouble
before with accessing libc symbols, which someone then decided to stop
exporting.  In this case, the intercepted symbol probably needs to be
exported, but the collector otherwise has to know a lot of stuff that
might change with libstdc++ changes.  (Maybe you should try posting your
patch to the libstdc++.  That might scare them into adding a hook :-) )

Could we get away with instead defining a GC_THROW macro that copies the
object to a GC-visible location (probably just with a bit-wise copy, to
make sure it's a shallow copy), before it does the actual throw?

Would it be much of a problem to restrict clients to one in-flight
exception at a time, per thread?  I don't remember the detailed C++
exception rules, but that seems to be the more tractable case anyway.
And that might make it possible to dodge the issue of when to throw away
the saved copy, without requiring changes to the handler.

I admit that solution is also ugly, and that it requires client code
changes.  But the changes are only needed for exceptions that point to
garbage collected memory.  Since this problem hasn't generated many
complaints yet, I'm hoping such code is rare?

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Filip Pizlo
> Sent: Sunday, January 22, 2006 4:34 PM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] workaround for C++ exceptions problem
> 
> 
> Hello,
> 
> Even if our request to add a hook to libstdc++ is approved, the  
> interaction between exceptions and GC will still be problematic on  
> older versions of gcc.  For this reason, I decided to take a 
> crack at  
> developing a small hack that overrides the routines that 
> allocate C++  
> exception storage.  I include a tarball of what I've done.
> 
> The idea is to override the two routines from eh_alloc.cc and expose  
> two function pointers that can be set to point at  
> GC_malloc_uncollectable/GC_free.
> 
> I tested this on my Mac with two different compilers (Apple GCC 3.3  
> and 4.0).
> 
> Most of the action here happens in configure.ac.  I've put comments  
> in this file describing how it detects the relevant information.  It  
> isn't pretty, but it should just work.
> 
> The idea would be to make this part of the GC.  That is, the 
> relevant  
> bits of autoconf code could be integrated right into the GC's  
> autoconf script, and activated when the user asks for C++ support.   
> The exoverride.cpp file could easily be made part of the GC sources.
> 
> -Filip
> 
> 
> 



More information about the Gc mailing list