why debian uses --use-cxa-atexit

why debian uses --use-cxa-atexit

[Jack Howarth]

   I've gone back through the debian-gcc mailing list and found
the origin of debian using --use-cxa-atexit in their gcc 3.x
compiler builds. It is in the thread starting with...

http://lists.debian.org/debian-gcc/2001/debian-gcc-200106/msg00126.html

which basically says that they are using --use-cxa-atexit because
global destructors are not run in the correct order. They got this
from http://gcc.gnu.org/bugs.html#known which has...

Global destructors are not run in the correct order.

Global destructors should be run in the reverse order of their constructors completing. In most cases this is the same as the reverse order of constructors starting, but sometimes it is different, and that is important. You need to compile and link your programs with --use-cxa-atexit. We have not turned this switch on by default, as it requires a cxa aware runtime library (libc, glibc, or equivalent).

Is this information still accurate for gcc 3.1? It would seem this is the 
only reason debian is using --use-cxa-atexit. Thanks for any clarifications.
                      Jack

Re: why debian uses --use-cxa-atexit

[Jakub Jelinek]

On Sat, Jun 01, 2002 at 07:21:20PM -0400, Jack Howarth wrote:
>    I've gone back through the debian-gcc mailing list and found
> the origin of debian using --use-cxa-atexit in their gcc 3.x
> compiler builds. It is in the thread starting with...
> 
> http://lists.debian.org/debian-gcc/2001/debian-gcc-200106/msg00126.html
> 
> which basically says that they are using --use-cxa-atexit because
> global destructors are not run in the correct order. They got this
> from http://gcc.gnu.org/bugs.html#known which has...
> 
> Global destructors are not run in the correct order.
> 
> Global destructors should be run in the reverse order of their
> constructors completing. In most cases this is the same as the reverse
> order of constructors starting, but sometimes it is different, and that
> is important. You need to compile and link your programs
> with --use-cxa-atexit. We have not turned this switch on by default, as
> it requires a cxa aware runtime library (libc, glibc, or equivalent).
> 
> Is this information still accurate for gcc 3.1? It would seem this is the 
> only reason debian is using --use-cxa-atexit. Thanks for any clarifications.

It is not about being or not being accurate for gcc 3.1, it is about glibc
2001-02-26 or later having:

/* This is defined by newer gcc version unique for each module.  */
extern void *__dso_handle __attribute__ ((__weak__));

/* Register FUNC to be executed by `exit'.  */
int
atexit (void (*func) (void))
{
  return __cxa_atexit ((void (*) (void *)) func, NULL,
                       &__dso_handle == NULL ? NULL : __dso_handle);
}

/* Hide the symbol so that no definition but the one locally in the
   executable or DSO is used.  */
#ifdef HAVE_DOT_HIDDEN
asm (".hidden\tatexit");
#endif

in /usr/lib/libc_nonshared.a (and exporting atexit from libc.so only
as compatibility symbol version, so nothing newly linked can use it).

	Jakub

Re: why debian uses --use-cxa-atexit

[Nathan Sidwell]

Jakub Jelinek wrote:
> 
> It is not about being or not being accurate for gcc 3.1, it is about glibc
> 2001-02-26 or later having:
> 
> /* This is defined by newer gcc version unique for each module.  */
> extern void *__dso_handle __attribute__ ((__weak__));
> 
> /* Register FUNC to be executed by `exit'.  */
> int
> atexit (void (*func) (void))
> {
>   return __cxa_atexit ((void (*) (void *)) func, NULL,
>                        &__dso_handle == NULL ? NULL : __dso_handle);
> }
it is the address of  __dso_handle which is needed. We'd misinterpreted
the spec until Mark applied
2002-04-15  Mark Mitchell  <mark@codesourcery.com>

        * decl.c (register_dtor_fn): Pass the address of dso_handle, not
        dso_handle itself, to __cxa_atexit.

so that call should really be
  return __cxa_atextit ((void (*) (void *)) func, NULL, &__dso_handle);

(previously __dso_handle was inited to its own address, so your
code would work for g++ produced objects, but not necessarily for others.)

nathan
nathan
-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org