From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 1856E3856DD3 for ; Tue, 23 Aug 2022 13:40:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1856E3856DD3 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id B96821FA1A; Tue, 23 Aug 2022 13:40:55 +0000 (UTC) Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id AFD832C141; Tue, 23 Aug 2022 13:40:55 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id A667E6806; Tue, 23 Aug 2022 13:40:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id A48B9674F; Tue, 23 Aug 2022 13:40:55 +0000 (UTC) Date: Tue, 23 Aug 2022 13:40:55 +0000 (UTC) From: Michael Matz To: Florian Weimer cc: binutils@sourceware.org, gcc@gcc.gnu.org, libc-alpha@sourceware.org Subject: Re: Counting static __cxa_atexit calls In-Reply-To: <87fshn2mu1.fsf@oldenburg.str.redhat.com> Message-ID: References: <87fshn2mu1.fsf@oldenburg.str.redhat.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2022 13:41:00 -0000 Hello, On Tue, 23 Aug 2022, Florian Weimer via Gcc wrote: > We currently have a latent bug in glibc where C++ constructor calls can > fail if they have static or thread storage duration and a non-trivial > destructor. The reason is that __cxa_atexit (and > __cxa_thread_atexit_impl) may have to allocate memory. We can avoid > that if we know how many such static calls exist in an object (for C++, > the compiler will never emit these calls repeatedly in a loop). Then we > can allocate the resources beforehand, either during process and thread > start, or when dlopen is called and new objects are loaded. Isn't this merely moving the failure point from exception-at-ctor to dlopen-fails? If an individual __cxa_atexit can't allocate memory anymore for its list structure, why should pre-allocation (which is still dynamic, based on the number of actual atexit calls) have any more luck? > What would be the most ELF-flavored way to implement this? After the > final link, I expect that the count (or counts, we need a separate > counter for thread-local storage) would show up under a new dynamic tag > in the dynamic segment. This is actually a very good fit because older > loaders will just ignore it. But the question remains what GCC should > emit into assembler & object files, so that the link editor can compute > the total count from that. Probably a note section, which the link editor could either transform into a dynamic tag or leave as note(s) in the PT_NOTE segment. The latter wouldn't require any specific tooling support in the link editor. But the consumer would have to iterate through all the notes to add the individual counts together. Might be acceptable, though. Ciao, Michael.