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.133.124]) by sourceware.org (Postfix) with ESMTPS id 99461385C413 for ; Wed, 24 Aug 2022 14:31:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 99461385C413 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=1661351496; 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: in-reply-to:in-reply-to:references:references; bh=U1Oai0Lk7jT6XNTtjbDuMRZb5hSGMJdDK8NsPu71xFc=; b=hNv9ZeitQkw64Lijsnqy5VHvmuaNb+s/RYWLeFRDsx0N5d5Ajt2HpgtIgbeEb3eJQcycAB a8CmixwYKlwDfgucSzJHxRs2r0HyJbxfiDuPMyBc0gQbHIQZwuGjYZgIRSBr7g/LCW6zS4 BKxZfxb8MmeI16f8LsymQR9uusoew8s= 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-652-y5z6hDNJMWuX_rEmWvAIFw-1; Wed, 24 Aug 2022 10:31:31 -0400 X-MC-Unique: y5z6hDNJMWuX_rEmWvAIFw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9FF81884EC2; Wed, 24 Aug 2022 14:31:28 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.78]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D3C40945D7; Wed, 24 Aug 2022 14:31:27 +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> <87k06x7sme.fsf@oldenburg.str.redhat.com> Date: Wed, 24 Aug 2022 16:31:26 +0200 In-Reply-To: (Michael Matz's message of "Wed, 24 Aug 2022 12:53:33 +0000 (UTC)") Message-ID: <87y1vd67cx.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.79 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 Wed, 24 Aug 2022, Florian Weimer wrote: > >> > 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). > > Makes sense. Though that actually hints at a design problem with ELF > static ctors/dtors: they should be able to soft-fail (leading to dlopen or > pthread_create error returns). So, maybe the _best_ way to deal with this > is to extend the definition of the various object-initionalization means > in ELF to allow propagating failure. We could enable unwinding through the dynamic linker perhaps. But as I said, those Itanium ABI functions tend to be noexcept, so there's work on that front as well. For thread-local storage, it's even more difficult because any first access can throw even if the constructor is noexcept. >> > 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? > > Hmm. The __cxa_atexit calls are coming from the per-file local static > initialization_and_destruction routine which doesn't have vague linkage, > so its contribution to the overall number of cxa_atexit calls doesn't > change from .o to final-exe. Can you show an example of what you're > worried about? Sorry if I didn't use the correct terminology. I was thinking about this: #include template struct S { static std::vector vec; }; template std::vector S::vec(i); std::vector & f() { return S<1009>::vec; } The initialization is deduplicated with the help of a guard variable, and that also bounds to number of __cxa_atexit invocations to at most one per type. > A completely different way would be to not use cxa_atexit at all: allocate > memory statically for the object and dtor addresses in .rodata (instead of > in .text right now), and iterate over those at static_destruction time. > (For the thread-local ones it would need to store arguments to > __tls_get_addr). That only works if the compiler and linker can figure out the construction order. In general, that is not possible, and that case seems even quite common with C++. If the construction order is not known ahead of time, it is necessary to record it somewhere, so that destruction can happen in reverse. So I think storing things in .rodata is out. Thanks, Florian