This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Use of atexit for destructors on Solaris 7.


 > From: Mike Stump <mrs@windriver.com>
 > 
 > > From: "Ross Smith" <ross.s@ihug.co.nz>
 > > To: <gcc-bugs@gcc.gnu.org>
 > > References: <200003211545.KAA19882@jaj.com>
 > > Date: Wed, 22 Mar 2000 07:51:55 +1200
 > 
 > > That limit applies to atexit() functions, not destructors. The
 > > standard doesn't give an implementation any licence to ignore
 > > destructors. If there is a fixed upper limit on atexit() functions
 > > on a system, then it follows that no compiler on that system is
 > > allowed to use atexit() for destructors.
 > 
 > Yes and no.  Is is allowed that implementations have limitations.  See
 > Annex B of the Standard.  So, one cannot argue this point in your
 > favor from the Standard, other than maybe g++ should document this.
 > 
 > > This may be a big problem for us if it's true. I've been working on
 > > a major project for which Solaris will be one of the targets, and if
 > > we can't get a reliable compiler we're screwed.
 > 
 > I'd recommend writting a linked list atexit routine, and using your
 > own in preference to the one in the system library.  You could then
 > push a call to call it on the real atexit chain.
 > 
 > That is the best short term fix.  Longer term, I think we need to push
 > library vendors for dynamic atexits.  Mid term, maybe gcc should
 > include an atexit routine on systems that have low static limits on
 > atexits.
 > 
 > You're not the only one puzzling over this...


Wow, no kidding?  That's really surprising.

The funny thing is that gcc already has an atexit implementation in
libgcc2.c which is dynamic.  But its only used on systems with no
atexit at all.  So really old systems end up in better shape than the
latest solaris2. :-)

Ross, I think if you stuck #define NEED_ATEXIT in sol2.h and
rebootstrapped, the libgcc2.c dynamic atexit would supercede the
solaris atexit for all programs copiled with gcc.

Give it a try at let me know if your testcase passes.

Mike, I don't have a lot of confidence in pushing vendors.  IMHO we
should either always use the libgcc2.c atexit or change g++ to
generate calls to some new function in libgcc2.c which keeps a dynamic
list of destructors and register just that one function with system
atexit so the destructor limit is always dynamic.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]