[K42-discussion] Cause of cxa_atexit/dso_handle reference

[Bryan S Rosenburg]

Patrick Bridges wrote on 08/23/2006 03:56:32 PM:
> 
> On Aug 23, 2006, at 1:52 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.
> 
> Well, we'll need a version for k42 libc anyway that works, since we 
> *will* want to support global objects there, right? 

It's not so clear to me that we need to support global objects in the K42 
library any more than in the kernel.  I view the K42 library as 
operating-system code that resides in the application address space but is 
largely isolated from the application.  The library survives across both 
fork and exec, for example, so "atexit" isn't particularly well defined. 
So I'd still say that if it's too painful to avoid the need for 
cxa_atexit(), we should just provide one that doesn't do anything.  No 
global K42 object should depend on a destructor to do anything useful.

We certainly need to support global objects in the application, but that 
support should come from glibc, not from K42.

- Bryan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/k42-discussion/attachments/20060823/9999af07/attachment.htm