From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99672 invoked by alias); 18 Oct 2019 12:10:29 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 99544 invoked by uid 89); 18 Oct 2019 12:10:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=tends X-HELO: mx1.redhat.com From: Florian Weimer To: libc-alpha@sourceware.org Subject: ELF destructor order vs constructor order Date: Fri, 18 Oct 2019 12:10:00 -0000 Message-ID: <87k192tftb.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-10/txt/msg00548.txt.bz2 Suppose that the constructors for object A run before the constructors for object B. (For the following, it does not matter how A and B were loaded.) Should it be possible that as the result of a dlclose call (or process termination), the destructors for A also run before the destructors for B? Or should the destructors always run in the reverse order of construction (assuming they happen during the same dlclose call)? I think the answer should be that the reverse order is used. We have a downstream report where a developer points out that they perceive the destructor order more or less as random (in #1133521, unfortunately not a public bug). The reason is that the C++ compiler tends to vary its emitted symbols with optimization settings and code changes, and the dependencies recorded during lazy binding currently end up changing the destructor order. I think we should disregard the dynamic dependency information and always perform the destructor calls in reverse order of the constructor calls (for the objects that are about to be unloaded). Comments? Thanks, Florian