From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74271 invoked by alias); 14 Jun 2019 12:29:57 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 74251 invoked by uid 89); 14 Jun 2019 12:29:57 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=HX-Received:adf X-HELO: mail-wr1-f54.google.com Received: from mail-wr1-f54.google.com (HELO mail-wr1-f54.google.com) (209.85.221.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 14 Jun 2019 12:29:55 +0000 Received: by mail-wr1-f54.google.com with SMTP id n4so2366784wrs.3; Fri, 14 Jun 2019 05:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=7U2VdOovRMGV+EAV3IT3e8h6QmkTSDT/nL507imFWlQ=; b=nTbhai/ZORk+5YepWIr6a5lnsQxvd19YIPpCbdOfdU3K1u3hfd/nuvzudgWtPBQ85N FrT6RYLMeeU505jh4mRbTZMcz24deALQd3GFJF9xriyxEwQIY1GeChP8sevchBD+D6fY J9EhyL9hKaPpvp2dCTaWgYQpEkXbirw4KgREHq/T2aRao8BVdP8BrxKhg/cYXuLA/amJ hII1OKwsssGPW8lw4yXKfEBhjBlqH89Jv1h1mkdO33dVSNGL+U4o2jvpQVoZ7YIs/0Xg 146Nk5+OQKGJDgr9o55XgKV/WYpH244dUfBmuLq0Zffc/OLs0iO7A2eUxZIin2Ev0mEl JJ7g== Return-Path: Received: from [192.168.0.160] ([151.69.16.169]) by smtp.googlemail.com with ESMTPSA id f13sm4530026wrt.27.2019.06.14.05.29.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Jun 2019 05:29:52 -0700 (PDT) Subject: Re: Problem with atexit and _dl_fini To: libc-help@sourceware.org, libc-alpha@sourceware.org References: <87blzypg5j.fsf@mid.deneb.enyo.de> <0a7c2435-43f8-8dfb-83ab-22ceff7ca51c@mulle-kybernetik.com> <9497a5c2-0dc8-18fe-6120-deb551f7ddd8@mulle-kybernetik.com> <31060c89-404f-e8e1-6c18-d75e0b63f6ad@linaro.org> <174f19a0-40ea-a5b1-d21d-3903f9bba9f8@mulle-kybernetik.com> From: Manfred Message-ID: <5341457e-6675-f515-7f25-5e6bbe4798dd@gmail.com> Date: Fri, 14 Jun 2019 12:29:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00024.txt.bz2 Interesting, In fact the link you posted is about the LSB, not specific to the Itanium C++ ABI, and indeed it does the right thing. As a side note, it leaves up to user code the following: - do not register with atexit functions residing in dso's that can be unloaded early (i.e. by dlclose() during execution, not at exit()). - do not instantate global/static C++ objects whose type is defined in the main program and derived from classes defined in dso's that can be unloaded early. Both requirements descend (implicitly?) from the C and C++ standards, though. I'm cross-posting to alpha, in case anyone is interested. On 6/14/2019 12:53 AM, Nat! wrote: > Funnily enough, if you read the Itanium C++ ABI, on which __cxa_finalize > is based, then the algorithm described > there is doing exactly the right thing. > Beause the wording of __cxa_finalize is so shortened, it its hard to > pick out the original meaning. But the description is > actually fully compatible with how `atexit` is supposed to function. > > The gist is this. For atexit, functions are stored in a unique way in > the termination function table (clarifications in []): > > http://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic.html#BASELIB---CXA-FINALIZE > > > ``` > In the latter case [atexit] the pointer to the function is the pointer > passed to atexit(), while the other pointers [operand, handle] are NULL. > ``` > > When dlclose hits, the handle to be closed is `d` and not NULL: > > ``` > The implementation shall arrange for__cxa_finalize() to be called during > early shared library unload (e.g. dlclose()) with a handle to the shared > library. > ``` > > And then > > ``` > When __cxa_finalize(d) is called, it shall walk the termination function > list, calling each in turn if d matches the handle of the termination > function entry. > ``` > > So `atexit`s don't match, since the handle stored is NULL. Only if `d` > is NULL (the base process terminates), then will the atexits be called. > Currently though at `dlclose` time all handlers are called, which breaks > the `atexit` specification as well as your own LSB. > > Well it's a goof up, but FreeBSD and MacOS aren't doing any better. > > Ciao >   Nat! > >