From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc34.google.com (mail-oo1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) by sourceware.org (Postfix) with ESMTPS id 421453858284 for ; Tue, 30 Aug 2022 12:56:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 421453858284 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oo1-xc34.google.com with SMTP id t15-20020a4a96cf000000b0044e0142ec24so685710ooi.8 for ; Tue, 30 Aug 2022 05:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc; bh=DxhIqmUi3zjfOc7zbtK43JyVW3oawwkL03NJC2CX5y4=; b=BbTjP4pVwcUwoVnauacK5DeigRUtdvc8j0gqS9JQYNQ7371/Talo/M5kXM9IjTZlWi gFAk1cp3qL28Sk5Hogw97yCoaV4v6VOeOzMp2PT0/PeGKyZlCpTtCOr2+MeDkCI00NUy ZqsLRos2jTEQt3paQrQ/5iA54ANat6QATXJoGPsjS7gy3+TJmFUcxBIFNZrJwoGKBjS8 LYkmYrI9LH1lOXngL0Mt5g0/GG1dtqfJwR6INH/I+SDPBAFNbMh9pHGxu7yDCEbTsj4i 00eDrxBFXD2A+5PQvOFKeVw9CcDxBugDPniOHetj6aB9lE37LP1uMfX5NR1Co9hQzpu0 JUiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc; bh=DxhIqmUi3zjfOc7zbtK43JyVW3oawwkL03NJC2CX5y4=; b=YmHHG4v/KnSfS4iquNo1++oE4+UTprras2A9mIimnUh3IpAbh6bJFkdB949thw/qqM IucsAhZpaZTSZMPUI0ODvgOguWl5M1IUd2ydDwymA6eVU9DFDVUy9JGO/6vxmn9JwBMj jyl3lIfVSXlZhHe2pOLbhv/scfyxRwlHJNZpQh90uwu5fQsfOFiwZa/cUpe6zifzQ/lb wKGml1nJ4jCB/1DZ/2890zgKfBcsYkT/JFZygkdsQotubSMnaZAM9ua69o3YLjBxVgAB wucnol7xQ7Duqx8lzeR8B85FGOsY+Jb6KJQSW+NzcCKSDA003GL9riQ8OVlF+zFzbcM+ oBpA== X-Gm-Message-State: ACgBeo0g+T+xR5y4O/rb3pm31aNA9K/lvvHpsftHtexsflha81H4Lsn0 SiQXe7Ih03EGUPBleYCK4qis/g== X-Google-Smtp-Source: AA6agR6JMAdmsyN+MChuVucDES+3dTnjYema0NNckATzQ9qpa46rWFjfKcmQ4wxJqxOdnSeyzqEylg== X-Received: by 2002:a4a:ba95:0:b0:44b:499f:793d with SMTP id d21-20020a4aba95000000b0044b499f793dmr7099893oop.68.1661864171655; Tue, 30 Aug 2022 05:56:11 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c0:745e:449b:a205:b33e:4a53? ([2804:1b3:a7c0:745e:449b:a205:b33e:4a53]) by smtp.gmail.com with ESMTPSA id r8-20020a056830236800b0063922f00ee2sm7342972oth.39.2022.08.30.05.56.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Aug 2022 05:56:11 -0700 (PDT) Message-ID: Date: Tue, 30 Aug 2022 09:56:09 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.0 Subject: Re: Calling __cxa_thread_atexit_impl directly, from C code Content-Language: en-US To: Florian Weimer Cc: libc-alpha@sourceware.org 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> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <87pmgi5gi6.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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 List-Id: 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 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? 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.