From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) by sourceware.org (Postfix) with ESMTPS id 687AF3858C2C for ; Mon, 29 Aug 2022 18:59:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 687AF3858C2C 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-oi1-x22f.google.com with SMTP id o184so11414642oif.13 for ; Mon, 29 Aug 2022 11:59:04 -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 :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc; bh=k4lbh8FBjvbVtwUB0mG6VqkBE88Ap/I2jnKLeMG9jc4=; b=o9olcsMgQyyCy3PM/zAGxpxNoHht8GuvWWkfFXAW1fcfOWvEJqUlGudNp67+O51QK5 rzbVFfXFn6FXyq2Rb8zo7Dj1KiIW7y9aC41Gmsh26d/cdtHito3u5rDiwdOwo0lTPh2s mwuaFwJn15IwgyIHIkRLdEOpn+WiH2P2/jWqcUiLLHa+V0JG0CFKtSimHJF8X1gq9kRH OYccY52hVelArxKKBVMSvTt/193fhGLsTb6Smmqr0BI/S2LYG3gZgBIt81iQXxpfcyPZ fkeGU5OuYXG/trXJgWH8GG+8MOGQojNF0VrVic7dTOjNXDXsP/vuBjTrY7dv/kTu+tZa rIqg== 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 :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=k4lbh8FBjvbVtwUB0mG6VqkBE88Ap/I2jnKLeMG9jc4=; b=pn4V1ToTipX0izolyeCXrHh1BJGNXqR55TixAgiuyW608IQZ7RsrlMmgDa5kDfUm0v kxPn4jKG/SqyrDNZuaQ6gfK/5qa+/GPOhUAvZZS8TreNZPd3By0YHbLpXPz0QmAVQGSB pmFg02zr/ioTOqGqRtrhT9SbHlre8THbTW3e4/pmzirzQh1x4ckED/RnfATuUzDaf1+U +aEKXTLoMl0Y2ZSMCpPXKEWSf6zKLgNLBUwD3koyPiWxJhLdpRnhLIqRU/txMVR1iFkv 6cT/ugiCE26u6B+CQzMBogX0t9FsWxBdCKyRgso7zjs+OZbYro1RQei0GZ+vRE90SYr1 OuRw== X-Gm-Message-State: ACgBeo01MdVtWRGKtB1oPax/74IcS05K71gLgUw325aeXU8UEawYlja2 a2ZxMZbFe16EkfCN5mEiIHR2FA== X-Google-Smtp-Source: AA6agR6SRUNyuOTfqWbcJiy94ALH5WqkiG2qTsm4ZR7sOXQ145OOYtxh5C1TMFyfvjDa+q9bwIe5UQ== X-Received: by 2002:a05:6808:1a11:b0:343:14aa:f973 with SMTP id bk17-20020a0568081a1100b0034314aaf973mr7549909oib.149.1661799543062; Mon, 29 Aug 2022 11:59:03 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c0:745e:189c:ed50:a343:6adf? ([2804:1b3:a7c0:745e:189c:ed50:a343:6adf]) by smtp.gmail.com with ESMTPSA id g17-20020a544f91000000b0033a11fcb23bsm5152958oiy.27.2022.08.29.11.59.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Aug 2022 11:59:02 -0700 (PDT) Message-ID: Date: Mon, 29 Aug 2022 15:59:00 -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 , libc-alpha@sourceware.org References: <87lerbtnh4.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <87lerbtnh4.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.5 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 26/08/22 05:31, Florian Weimer via Libc-alpha wrote: > Do we support calling __cxa_thread_atexit_impl directly? The function > is not documented, nor is it declared in any installed header. > > I think the answer is yes, because we support different C++ > implementations, and they have to call __cxa_thread_atexit_impl for > thread-local destructors, either directly or through a wrapper > (__cxa_thread_atexit for libstdc++, as proposed for the Itanium C++ > ABI). Not only that, but if the C library does not provide the C++ replacement will most likely have serious drawbacks such as no handling of dso_symbol (so no synchronization between thread_local destructors and dclose) and no ordering enforcing in main thread thread_local destructors. The libc++ implementation does document the possible issues with the fallback. > > There's interest in this because it's much easier to use than > pthread_key_create if you have to avoid linking against libpthread and > you target glibc releases between 2.18 and 2.33 (although it is possible > to use weak symbols, as in the libstdc++ implementation in > libstdc++-v3/libsupc++/atexit_thread.cc). Although it seems to be used solely by C++ and the interface is generic enough so any runtime/language might use it as well for any thread exit deallocation cleanup, I am not sure it would be feasible to export or support calling it from C code. It does make sense to use __cxa_thread_atexit for C++ since it aims to have interoperability with C, but it is not clear to me how useful it would be for a language or runtime that does not aim for it (it would be simple to just do all the required work on the thread wrapper or similar facility). The interface also have two annoying peculiarities where calling from C code is not straightforward: 1. Any memory failure aborts the process, which is far from ideal to a generic interface. 2. User need to correctly declare __dso_handle; using NULL (or any invalid value) will bound the to callback to main program (which is not correct if use within a shared library). So I think it would be better to provide a different interface.