[K42-discussion] Cause of cxa_atexit/dso_handle reference

Bryan S Rosenburg rosnbrg at us.ibm.com
Fri Aug 25 08:23:05 EST 2006


Donour Sizemore wrote on 08/24/2006 01:11:58 PM:
> Bryan S Rosenburg wrote:
> > 
> > I'm sorry for not being more responsive.  As Orran said, we're really 
> > busy working toward an internal milestone for the next few weeks.
> > 
> > I'm still in favor of avoiding global objects on general principles, 
but 
> > not if it involves solving too many case-by-case problems.  I think 
the 
> > particular DeletedObject case can be solved with a dynamic allocation 
> > using the "primitive" memory allocator.  I've attached a patch below. 
> >  The patch compiles, but I haven't tested it, and I certainly haven't 
> > verified that it avoids the cxa_atexit requirement.
> > 
> > If there are too many cases, or if there are cases that can't be 
easily 
> > resolved, I'd fall back on providing a cxa_atexit() that doesn't do 
> > anything.  There's really no point in recording the cleanup functions 
> > when there's no code that will ever call them.
> > 
> > Here's the patch for dynamically allocating theDeletedObj: 
> > 
> 
> I just tried this patch, but gcc still emits the __cxa_atexit symbol. I 
> have a solution that adds the aforementioned empty atexit function, 
> along with the necessary changes to makefiles. I'll post it shortly.

My patch fixed just one example of a global object that now has a 
destructor.  No one expected the patch to all by itself eliminate all 
references to __cxa_atexit.  How many problematic global objects are 
there?  Are any of them hard to fix?  It may well be necessary to take 
your approach, but I'd at least like to know the magnitude of the problem 
before we bail out.

- Bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/k42-discussion/attachments/20060824/ec8449fa/attachment.htm 


More information about the K42-discussion mailing list