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 131313858C74 for ; Mon, 15 Jan 2024 19:43:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 131313858C74 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 131313858C74 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705347790; cv=none; b=U6don0FFTcM4fTroTyDtapDISju2/zCB1WDqGV0Lf64Ghlz3DRK8h5Ax/WpNfqGppXahyTq4VkcyET92jlxWgduQpE1JMccXO973HPtcrrwzme8yxEXABNrs3ytQu785dZ2lCzKc4Yj+g4BJqYrm49XqZZ+yjcrbfGBa9NTxgB0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705347790; c=relaxed/simple; bh=beCfpFipTod6zZ+9+ytHHp3IRcdD+iR6lhmvW8+69OY=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=MsCVOOQhEv1LZQWFnRmgHTvWwINWB1DpixxZ/dPYkaB9eAh75OAcp9gjJczcrnnOD6HZuyACanEOgStjs7zrrbh9Sfm/Q2C+KFiA0MQoiEwWalHe+As4ugKnyUAclAAPtRe2JSj85pf84xKG60ukioPD1y39nOXeqmnIGAGt0HM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1705347787; 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=aUY8lYENpO0Nrcn+hDX/OKz0HEGXiB8hZN2OMV0IQc8=; b=i40xi4lMqnyrXfz8/uBrRvpNvfHXsXug1zFSiCt7CttZIUP0S/z0PKocsdRsTSVWLVExJL EIQ8VkzlYcB5qs1d7r2aaZ36NOqLzfbF4GDfmvop+VVTqo5JO3x7DDWF5NJiDo2i8HuLrM DD9RrdEH/LYS6G0gvSByiMu4CrifF6k= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-403-NAbXtYFKM8ad0nKKLBxnFA-1; Mon, 15 Jan 2024 14:43:05 -0500 X-MC-Unique: NAbXtYFKM8ad0nKKLBxnFA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D9B54280A9B2; Mon, 15 Jan 2024 19:43:01 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.140]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D3D14C15E6C; Mon, 15 Jan 2024 19:42:59 +0000 (UTC) From: Florian Weimer To: Mathieu Desnoyers Cc: gcc@gcc.gnu.org, libc-alpha@sourceware.org, Iain Sandoe , aburgess@redhat.com, lttng-dev@lists.lttng.org, Szabolcs Nagy Subject: Re: [lttng-dev] New TLS usage in libgcc_s.so.1, compatibility impact References: <8734v1ieke.fsf@oldenburg.str.redhat.com> <1c32a469-9bef-4b04-9696-0f875bb3727f@efficios.com> Date: Mon, 15 Jan 2024 20:42:58 +0100 In-Reply-To: <1c32a469-9bef-4b04-9696-0f875bb3727f@efficios.com> (Mathieu Desnoyers's message of "Mon, 15 Jan 2024 14:05:32 -0500") Message-ID: <87ply24c3h.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 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.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,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: * Mathieu Desnoyers: > On 2024-01-13 07:49, Florian Weimer via lttng-dev wrote: >> This commit >> commit 8abddb187b33480d8827f44ec655f45734a1749d >> Author: Andrew Burgess >> Date: Sat Aug 5 14:31:06 2023 +0200 >> libgcc: support heap-based trampolines >> Add support for heap-based trampolines on x86_64-linux, >> aarch64-linux, >> and x86_64-darwin. Implement the __builtin_nested_func_ptr_created and >> __builtin_nested_func_ptr_deleted functions for these targets. >> Co-Authored-By: Maxim Blinov >> Co-Authored-By: Iain Sandoe >> Co-Authored-By: Francois-Xavier Coudert >> added TLS usage to libgcc_s.so.1. The way that libgcc_s is >> currently >> built, it ends up using a dynamic TLS variant on the Linux targets. >> This means that there is no up-front TLS allocation with glibc (but >> there would be one with musl). > > Trying to wrap my head around this: > > If I get this right, the previous behavior was that glibc did allocate > global-dynamic variables from libraries which are preloaded and loaded > on c startup as if they were initial-exec, but now that libgcc_s.so.1 > has a dynamic TLS variable, all those libraries loaded on c startup that > have global-dynamic TLS do not get the initial allocation special > treatment anymore. Is that more or less correct ? Ahh. I had forgotten about this aspect. The allocation from the static TLS area still happens as before. > I've prepared a change for lttng-ust to move the lttng-ust libc wrapper > "malloc nesting" guard variable from global-dynamic to initial-exec: > > https://review.lttng.org/c/lttng-ust/+/11677 Fix: libc wrapper: use initial-exec for malloc_nesting TLS I don't know if this is completely sufficient if there are other TLS variables in the lttng stack. > This should help for the infinite recursion issue, but if my understanding > is correct about the impact of effectively changing the behavior used > for global-dynamic variables in preloaded and on-startup-loaded libraries > introduced by this libgcc change, I suspect we have other new issues here, > such as problems with async-signal safety of other global-dynamic variables > within LTTng-UST. This didn't change, and the allocation is not done lazily (contrary to what I might have written before). But even on the __tls_get_addr fast path, we check the TLS generation counter, and if that has changed, we do extra bookkeeping work. TLS usage in libgcc_s.so.1 means that in the now-failing test, the generation counter changed. Before bug 19924 TLS performance degradation after dlopen was fixed, we did not do this bookkeeping work, which is why the problem didn't occur. General use of lttng should be fine, I think, only the malloc wrapper has this problem. > 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? Thanks, Florian