__cxa_atexit and __cxa_finalize implementation

Joakim Tjernlund joakim.tjernlund at lumentis.se
Fri Sep 16 14:25:20 UTC 2005


> On Fri, 16 Sep 2005, Joakim Tjernlund wrote:
> 
> > >
> > > On Fri, 16 Sep 2005, Peter S. Mazinger wrote:
> > >
> > > > On Thu, 15 Sep 2005, Stephen Warren wrote:
> > > >
> > > > Attached are my patches:
> > > > nonshared:
> > > > -adds support generally for any files to uclibc_nonshared.a
> > > > -creates the needed linker script
> > > > -it does not check for existence of files (fails if no nonshared_obj.*
> > > > file is present)
> > > >
> > > > atexit:
> > > > adds atexit to nonshared lib, applies after the cxa_atexit... patch
> > > >
> > > > Be aware, this will for sure kill most of the apps (all that used atexit()
> > > > ) it will be an incompatible change to uClibc.
> > >
> > > I have "created" a compat old_atexit (really a copy of the new atexit,
> > > but not hidden), with weak_alias to atexit (that could allow updating)
> > >
> > > How will the linker script react for newly built binaries?
> > > /* GROUP ( /lib/libc.so.0 /usr/lib/uclibc_nonshared.a )
> > > Will the weak atexit from libc.so.0 be taken, or the hidden atexit from
> > > nonshared.a? I am hoping for the latter case ...
> >
> > Don't think so, the weak atexit will be taken before the one uclibc_nonshared.a
> > Possibly you could do:
> > GROUP ( /lib/libc.so.0 /usr/lib/uclibc_nonshared.a /some_path/compat_libc.so )
> > where compat_libc.so contains atexit(). Maybe you can add __libc_stack_end there too?
> > Jocke
> 
> why should it get it from compat_libc , but not from nonshared, the "rule"
> you are saying would apply here too? or do you think that shared libs have
> "priority" over archives?

uclibc_nonshared.a is used at linktime while compat_libc.so is used at runtime.
Any app that is compiled before uclibc_nonshared.a is introduced to uClibc will
use the compat_libc.so. When you relink the apps/libs, they will use uclibc_nonshared.a and
link atexit directly into the app/lib.

> 
> __libc_stack_end can be added too, but I wonder why glibc does not need
> it?

Perhaps because they have had __libc_stack_end for a long time already?

 Jcoke 




More information about the uClibc mailing list