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.133.124]) by sourceware.org (Postfix) with ESMTPS id AF6813858D37 for ; Mon, 12 Feb 2024 10:44:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AF6813858D37 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 AF6813858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707734664; cv=none; b=jieoP+m9r+7DDDMiHaaG+3Ym6hgE00Fb/7+Uea6xSKNQQ81R7Kk89XxrJ2o6R6Fj+mCePbX6OOSNKyNMGr+bI6BEa2TGKDIu7Z6ftd411hXfr5tPPEYBB4HhvjpP/R0Up41HeE69kIyIRYT6YURHz296O/K0H/TthpelQUJTgYQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707734664; c=relaxed/simple; bh=exFaAeuf9rge/spgFgxrg7ozYUGZiZqy+TNqhZNk9AU=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=J27rKA/FwJHO+MQVQg9+opcWifUcWDRn8Vzpi0bcVZcJOfx2+HCmW8qvoufLwM+KztQed5mmvnarZr5RKPa5EHsmrfYPewDUhIEMBl48hX53N8/EgoRGMoT8QI1ChumFZAAUIgimuwvMry90zEhpifec4ILfUNOLOv1/x78Dpds= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1707734659; 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=d/JfGwcMzw0J5Z8Oj4JfEK3KRupswfIevrNKwhBY0eg=; b=TMr9FNA6djEEN8rFwKLqyLDVXAIANlxFpyJRdgI8Zx+d352/eZj/YlBVr/fiUtpx6TdbyL 684YsywB2ZFRIn/K+oftkt6suDBTVnM1/F90hcBYgb9oSKnQFNwz7QILoeHRMxOA3mS44m 7GW2KM+kSnRn5AiwxkaE39ZURJ951Eg= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-414-Lrk3mRhmM8OA7SUzYoLHuw-1; Mon, 12 Feb 2024 05:44:18 -0500 X-MC-Unique: Lrk3mRhmM8OA7SUzYoLHuw-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (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 EE727185A797; Mon, 12 Feb 2024 10:44:17 +0000 (UTC) Received: from oldenburg3.str.redhat.com (unknown [10.39.192.236]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 22A2C492BF0; Mon, 12 Feb 2024 10:44:16 +0000 (UTC) From: Florian Weimer To: "H.J. Lu" Cc: libc-alpha@sourceware.org Subject: Re: [PATCH v2] x86-64: Update _dl_tlsdesc_dynamic to preserve vector registers References: <20240212031949.3041730-1-hjl.tools@gmail.com> Date: Mon, 12 Feb 2024 11:44:15 +0100 In-Reply-To: <20240212031949.3041730-1-hjl.tools@gmail.com> (H. J. Lu's message of "Sun, 11 Feb 2024 19:19:49 -0800") Message-ID: <87eddic680.fsf@oldenburg3.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.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.9 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: * H. J. Lu: > Compiler generates the following instruction sequence for GNU2 dynamic > TLS access: > > leaq tls_var@TLSDESC(%rip), %rax > call *tls_var@TLSCALL(%rax) > > CALL instruction may be transparent to compiler which assumes all > registers, except for RAX, are unchanged after CALL. At run-time, > _dl_tlsdesc_dynamic is called, which calls __tls_get_addr on the > slow path. __tls_get_addr is a normal function which doesn't > preserve any caller-saved registers. _dl_tlsdesc_dynamic saves and > restores integer caller-saved registers, but doesn't preserve any > vector registers which are caller-saved. Add _dl_tlsdesc_dynamic > IFUNC functions for FXSAVE, XSAVE and XSAVEC to save and restore > all vector registers. This fixes BZ #31372. What about the flags register? It's still clobbered. What about stack pointer alignment? > + /* Besides rdi and rsi, saved above, save rcx, rdx, r8, r9, > + r10 and r11. */ I would prefer to see some explicit ABI action first before making such decisions. Maybe %r11 could be a scratch register available for use by the TLSDESC call? Or does current GCC already assume that all scalar registers are preserved? The other way to fix this is to preallocate everything, so that the need for the slow path goes away. Thanks, Florian