From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) by sourceware.org (Postfix) with ESMTPS id 715D43858C74 for ; Mon, 15 Jan 2024 20:08:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 715D43858C74 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=efficios.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 715D43858C74 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=167.114.26.122 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705349316; cv=none; b=JNaTE7FTynnyIsaYdaEHqlYUFWE6Jg+O7WAvb4T8FaRpw6Dg3GrIfeSHsn91Dg0d+70LJEeeIC+C0bIxVbo9dpzzIO3BVEQ7rTgA5YjypQ8X5c8MkEyFoBXJMv3Ri5VyWT+Rgaij4OembnOZlQGD5zXjVlCJBvNZf8M+HrYJ9rQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705349316; c=relaxed/simple; bh=Z/G3JeVew3iiMplauyScBt6Wwxb696PqjkzXn+/0rLg=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=gpyELyQZF74tMSnCPU2rqBuPeGKulcqUMrKvE/ielvQtO9KGX9YME5NIxckiTw5z/84dwJW69bw/O1ILKwkP0RDohE9O8ZXYCc4Qs4dW6gL4Agd/ftKvchDkp27SO9Tt424qM5RV0vYs9V1awihccDJ31zlY+dzwDW5IH3ARxwE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1705349313; bh=Z/G3JeVew3iiMplauyScBt6Wwxb696PqjkzXn+/0rLg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=VHyHhh+qPxT+2PIX7rmy/IQe2cXDSjyMGramZlZ0WUcq8xgvR9DmmtH6+tKZ577je g5xvWck1ZTNQpspMlM+/E8ys/rp7rroldoXC1HxA1OWTVQBwQHDtrtiWSob0m8HvK2 Q0BUtxdbweYrVyxOEEdYEBJGIRVkgJkccnfIk096mPP0Iqx2OPp2PGZUH8L+obl3ng VimG1InXYZFs2LSFSCMfTb17/oP60MafsqoOdWssZbkN/lqy1HYPT4U6gtzKdJwa/o D0qPUhVmIaQi6xhgm8L2UFKGrGyANPdpA1Blh3L9rF0orwvFxphJBimH8tsAKurQlv 64OKzpSjNa7tw== Received: from [172.16.0.134] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4TDNW55T3LzKsL; Mon, 15 Jan 2024 15:08:33 -0500 (EST) Message-ID: <7e0e21b4-94f8-4ca5-8caf-31d8864a4ace@efficios.com> Date: Mon, 15 Jan 2024 15:08:33 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [lttng-dev] New TLS usage in libgcc_s.so.1, compatibility impact Content-Language: en-US To: Florian Weimer Cc: gcc@gcc.gnu.org, libc-alpha@sourceware.org, Iain Sandoe , aburgess@redhat.com, lttng-dev@lists.lttng.org, Szabolcs Nagy References: <8734v1ieke.fsf@oldenburg.str.redhat.com> <1c32a469-9bef-4b04-9696-0f875bb3727f@efficios.com> <87ply24c3h.fsf@oldenburg.str.redhat.com> From: Mathieu Desnoyers In-Reply-To: <87ply24c3h.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 2024-01-15 14:42, Florian Weimer wrote: > * Mathieu Desnoyers: > [...] > > General use of lttng should be fine, I think, only the malloc wrapper > has this problem. The purpose of the nesting counter TLS variable in the malloc wrapper is to catch situations like this where a global-dynamic TLS access (or any unexpected memory access done as a side-effect from calling libc) from within LTTng-UST instrumentation would internally attempt to call recursively into the malloc wrapper. In that nested case, we skip the instrumentation and call the libc function directly. I agree with your conclusion that only this nesting counter gating variable actually needs to be initial-exec. > >> But moving all TLS variables used by lttng-ust from global-dynamic to >> initial-exec is tricky, because a prior attempt to do so introduced >> regressions in use-cases where lttng-ust was dlopen'd by Java or >> Python, AFAIU situations where the runtimes were already using most of >> the extra memory pool for dlopen'd libraries initial-exec variables, >> causing dlopen of lttng-ust to fail. > > Oh, right, that makes it quite difficult. Could you link a private copy > of the libraries into the wrapper that uses initial-exec TLS? Unfortunately not easily, because by design LTTng-UST is meant to be a singleton per-process. Changing this would have far-reaching impacts on interactions with the LTTng-UST tracepoint instrumentation, as well as impacts on synchronization between the LTTng-UST agent thread and application calling fork/clone. Also AFAIR, the LTTng session daemon (at least until recently) does not expect multiple concurrent registrations from a given process. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com