From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id B41D1394D8F6 for ; Wed, 24 Aug 2022 12:07:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B41D1394D8F6 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661342820; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: references:references; bh=CxYWtXC1ItKq08F97uV8GsQfZ3j5a5BLkUeoPs6aVBc=; b=dHAE87NI9yDllSVAXibLmew84Bmeqmz8O/+YNfg/6lf0w6LDlRRxlL1BNs+ofIYntkjS4I 3i/1yHVKQjwZt0d+oyfEPtMdLRUb/rKNt7sc7B2KFjjUzw+C21ReqpLaWO5X7otDKEp9q+ 9TN+ENW00yhlFe0bs6zzsaMknCCxP6U= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-279-3yIM0MDFO9CF3aAVBH-G3g-1; Wed, 24 Aug 2022 08:06:53 -0400 X-MC-Unique: 3yIM0MDFO9CF3aAVBH-G3g-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9DC898041BE; Wed, 24 Aug 2022 12:06:52 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.78]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 632E62166B26; Wed, 24 Aug 2022 12:06:51 +0000 (UTC) From: Florian Weimer To: Michael Matz Cc: binutils@sourceware.org, gcc@gcc.gnu.org, libc-alpha@sourceware.org Subject: Re: Counting static __cxa_atexit calls References: <87fshn2mu1.fsf@oldenburg.str.redhat.com> Date: Wed, 24 Aug 2022 14:06:49 +0200 Message-ID: <87k06x7sme.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,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 List-Id: * Michael Matz: > 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? Yes, and that is a soft error that can be handled (likewise for pthread_create). > 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? We can report the error properly, and not just terminate the process. The existing ABI functions are mostly noexcept. For C++ constructors of global objects, there cannot even be a handler because they are invoked by an ELF constructor, and throwing through an ELF constructor is undefined. >> 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. I think we need some level of link editor support to avoid drastically over-counting multiple static calls that get merged into one implementation as the result of vague linkage. Not sure how to express that at the ELF level? Thanks, Florian