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 34E1A3858CDA for ; Tue, 6 Sep 2022 06:44:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 34E1A3858CDA 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=1662446659; 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=53hzPnRfkU8jLPtzMrhAZ0QfQy28e48BZzlCq03HzhY=; b=btijFOYeyjmKUT3P9WA5dheh5yObXSY/zpQeBAi0rYk0grN9BGBqA6g5dPhHRLgMaYs5FL xEYrokOChJRNP+O6Cm/oqgSClz8RmcpE1cO7zjf4Xf5isMnm98eL+LbbmGp988qC23okIy 40Cx3d4GA2lU8Wz/3gS2lT5eKsq39Ok= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-569-wnqeY6CiNKGhbPWWeAI56g-1; Tue, 06 Sep 2022 02:44:18 -0400 X-MC-Unique: wnqeY6CiNKGhbPWWeAI56g-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2332F1C07587; Tue, 6 Sep 2022 06:44:18 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.109]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4A257C15BB3; Tue, 6 Sep 2022 06:44:17 +0000 (UTC) From: Florian Weimer To: Adhemerval Zanella Netto Cc: libc-alpha@sourceware.org Subject: Re: Calling __cxa_thread_atexit_impl directly, from C code References: <87lerbtnh4.fsf@oldenburg.str.redhat.com> <87sfle26vf.fsf@oldenburg.str.redhat.com> <65d24a0f-2fc4-010f-e26a-a344e63a9d49@linaro.org> <87pmgi5gi6.fsf@oldenburg.str.redhat.com> Date: Tue, 06 Sep 2022 08:44:15 +0200 In-Reply-To: (Adhemerval Zanella Netto's message of "Tue, 30 Aug 2022 09:56:09 -0300") Message-ID: <87k06hatog.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.85 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.5 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: * Adhemerval Zanella Netto: > On 30/08/22 04:37, Florian Weimer wrote: >> * Adhemerval Zanella Netto: >> >>> It would mean that libgcc_s would need to build and use the fallback >>> implementation in the case of failure, which is suboptimal (although not >>> sure it would be an improvement over abort on failure). >> >> The fallback implementation also has to allocate memory. >> >> The alternative would be to throw std::bad_alloc. > > Yeah, but the suboptimal is not solely for the allocation memory part, > but also for the missing synchronization and ordering. But I also think > moving the failing handling to caller it still better than the hard hammer > or aborting the process (even though I agree it won't improve that much). But I think this argues indirectly for making a __cxa_thread_atexit_impl variant callable from C code: C++ code with -fno-exceptions might want to use this as well, and there is really no good way to handle such fallible C++ constructs (here: implicit destructor registration) without exceptions. >>> But I also think for compat reasons we can't really change >>> __cxa_thread_atexit_impl, since C++ constructors will be the ones responsible >>> to call __cxa_thread_atexit and afaik it assumes it can not fail (meaning >>> that any failure will be ignored). >> >> Yes, there is the general problem that for registering an object for >> destruction, as a matter of principle, you need to try to allocate the >> data structure in the registry first, and if that is successful, create >> the object. Otherwise you may end up with an object and no way to >> register its destructor. Perhaps you should just call the destructor at >> this point and throw std::bad_alloc. >> >> I guess we should go with the static destructor counting approach >> instead. 8-/ > > Why strategy more specially do you mean the counting approach? If we know how many TLS variables with d'tors there can be, we can allocate the memory upfront during thread creation. > I just reread the 'Counting static __cxa_atexit calls' thread and tend > to agree with you that having the number of required unique > __cxa_atexit calls seems slight better than a failable .init_array > mode. Please say so on the thread as well. 8-) Thanks, Florian