From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48844 invoked by alias); 12 Jun 2019 03:41:26 -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 48831 invoked by uid 89); 12 Jun 2019 03:41:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=H*M:572a X-HELO: mail-it1-f196.google.com Received: from mail-it1-f196.google.com (HELO mail-it1-f196.google.com) (209.85.166.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Jun 2019 03:41:24 +0000 Received: by mail-it1-f196.google.com with SMTP id m187so8536732ite.3 for ; Tue, 11 Jun 2019 20:41:24 -0700 (PDT) Return-Path: Received: from [192.168.8.101] ([67.69.69.230]) by smtp.gmail.com with ESMTPSA id h19sm5556883iol.65.2019.06.11.20.41.21 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jun 2019 20:41:22 -0700 (PDT) Subject: Re: Problem with atexit and _dl_fini To: Nat! , libc-help@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: Carlos O'Donell Message-ID: <2db62799-da59-572a-76c4-46a0b97982cf@redhat.com> Date: Wed, 12 Jun 2019 03:41:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00020.txt.bz2 On 6/11/19 6:40 PM, Nat! wrote: > Sorry for the spam, but I just thought of an easy fix for the situation, with this rewording of http://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic.html#BASELIB---CXA-FINALIZE > > ``` > 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. The unload should fail, if the termination function list contains any __cxa_atexit-registered functions. > When the main program calls exit, the implementation shall cause any remaining __cxa_atexit-registered functions to be called, either by calling __cxa_finalize(NULL), or by walking the registration list itself. > ``` > > The effect is, that atexit "poisoned" shared objects stay until termination, all others get unloaded as they are now, which would be IMO perfect and expected. As a positive side effect it seems like minimal code change. I disagree. It would block existing plugin mechanisms from being able to reload their objects until they switched to some other mechanism like destructors. It is a change which is not conservative and doesn't solve any real problems except an educational issue. -- Cheers, Carlos.