[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