This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Thread-local support for non-POD data objects

On Thu, Aug 01, 2013 at 10:48:08AM +0530, Siddhesh Poyarekar wrote:
> On 1 August 2013 09:19, Rich Felker <> wrote:
> > Since this is a new feature, my feeling is we should try to get it
> > right. There should be some way for the dynamic linker to know the
> > maximum number of __cxa_thread_atexit calls the library will make so
> > it can reserve space for them. Fixing plain __cxa_atexit can be a
> > separate issue.
> The way it is currently implemented, any fix that happens for this
> could be done for both __cxa_atexit and __cxa_thread_atexit.  The
> feature is already out with gcc-4.8, so major design changes may be
> difficult to make at this stage.  Maybe you could talk to the gcc
> folks and see if this is possible.

I see.

> > How many calls to __cxa_atexit does the compiler generate? Offhand it
> > looks like it generates one per object, which is really ugly and
> > inefficient; there's no reason for it to be more than one per
> > translation unit, and it could really be just one per dso with some
> > toolchain help, or even better, none at all, using fini_array instead.
> It uses the init_array/fini_array currently for __cxa_atexit, but it
> is still one call per object I think.

What I meant is that I don't see why it even needs to call a function
to register the dtors. It should just be able to put the dtors in the
fini array, which will automatically be run on program termination (or
dlclose unloading).


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