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 39D903858D32 for ; Mon, 29 Jan 2024 11:03:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 39D903858D32 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 39D903858D32 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=1706526185; cv=none; b=nFLfdXw/WkDRDSBqsK/C9Or9GSdDF3QejzsoewxcUL7VUF+k3a1h4MsubkkMmxl8B2/XV5EovO/BYlrl+IorovUJHGgx5VBIttM/TbzeBGh6eba3+dSwUcQ5ncJJmeQKDAlumKX+00osMZDNzDNTjRCqbgsVw07lLio0tpptfVQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706526185; c=relaxed/simple; bh=Ko1tVzVz1ItQGqszFbO8IRmubCUDWXUtMAWTimqiR/k=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=b87r4thSm0ACnA4qVBl4gGse2twGWSayzhwNYzCz3HSXrlOI0jyeABK9MI2dpBusCvkBt+KaIB+LZYbCPvurnVlnmyqgWfAxMr27ZWpyuY8wJNTF0nfEfoEwfu3JrG49/NwjiPC3oOPCXAaGucDDeESLWNI6JySyihKz4TKwWHg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1706526179; h=from:from:reply-to: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=dICdsX5QVuIA8ktmS21F8cWPlz9PfdVg2ogIOSIgCBA=; b=XZXkQ6gnvxIiAjfrmFs2mSZ6o+U2YeiYP0ELTgtWAZfO9K70yidgMHJyNGJlAkjFYpCyZt BLTSpz4MeQi67cKCkjTTCJwhSaMIcfRYJjIBR7SKIvIUpHyhm0lGKC7YLl944NVLtye5gA TNHenrhqnyDLZeE83Xnae3n9d8VghBE= 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-3-l1Sbcw-1Pt2uUoVq6hG9Ww-1; Mon, 29 Jan 2024 06:02:58 -0500 X-MC-Unique: l1Sbcw-1Pt2uUoVq6hG9Ww-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (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 34806101A526; Mon, 29 Jan 2024 11:02:58 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.70]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EE3791C060AF; Mon, 29 Jan 2024 11:02:57 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 40TB2t582973094 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 29 Jan 2024 12:02:55 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 40TB2tDc2973093; Mon, 29 Jan 2024 12:02:55 +0100 Date: Mon, 29 Jan 2024 12:02:54 +0100 From: Jakub Jelinek To: "H.J. Lu" Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Handle function symbol reference in readonly data section Message-ID: Reply-To: Jakub Jelinek References: <20240127151055.358066-1-hjl.tools@gmail.com> MIME-Version: 1.0 In-Reply-To: <20240127151055.358066-1-hjl.tools@gmail.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-4.0 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: On Sat, Jan 27, 2024 at 07:10:55AM -0800, H.J. Lu wrote: > For function symbol reference in readonly data section, instead of putting > it in .data.rel.ro or .rodata.cst section, call function_rodata_section to > get the read-only or relocated read-only data section associated with the > function DECL so that the COMDAT section will be used for a COMDAT function > symbol. I have to admit I still don't understand what the linker doesn't like on what GCC emits and why references to the public symbols at the start of comdat sections are ok in .text but not in .data.rel.ro but are in .data or .rodata sections (or what the exact rules are, see also what we emit on __attribute__((noinline, noipa)) inline void foo () {} void bar () { foo (); } void (*p) () = foo; void (*const q) () = foo; void (*const *r) () = &q; ). I've always thought that the problematic references are when something references non-public symbols in comdat sections, especially not at their start, because if linker selects some comdat section(s) from some other TU, there is no guarantee e.g. the code is identical (just in valid program should behave the same) and if such reference comes from other comdat that is kept or from non-comdat sections, the question is what should be referenced. But in this case, I believe we are referencing the function at the start of a code comdat section. Now, in my limited understanding what the patch does is totally wrong for multiple reasons. On the first testcase it changes - .section .data.rel.ro.local,"aw" + .section .data.rel.ro.local._ZN4blah17_Function_handlerIFvvENS_5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTools_FunctorInternalIN12_GLOBAL__N_19CountUsesIxEELb0EEExxxEEEE10_M_managerERNS_9_Any_dataERKSI_NS_18_Manager_operationE,"awG",@progbits,_ZN26vtkStaticCellLinksTemplateIxE18ThreadedBuildLinksExxP12vtkCellArray,comdat .align 8 .LC0: .quad _ZN4blah17_Function_handlerIFvvENS_5_BindIFPFvPvxxxEPN3vtk6detail3smp27vtkSMPTools_FunctorInternalIN12_GLOBAL__N_19CountUsesIxEELb0EEExxxEEEE10_M_managerERNS_9_Any_dataERKSI_NS_18_Manager_operationE Now, I believe such a .data.rel.ro.local.* section is normally used for .data.rel.ro.local constants from the referenced function, if we have some relocatable constant needed in that function we emit those there. If linker picks up the comdat from current TU, it will be all fine, sure, but if it picks up the comdat from another TU, the .data.rel.ro.local._ZN4blah17_Function_handlerIFvvENS_5* section there might not be present or might contain some unrelated stuff. Given the handling of (const (plus (symbol_ref) (const_int)), we also don't know whether the section holds a reference to the start, or to some other offset of it, how many etc. And, we refenre a non-public symbol (.LC0) from non-comdat section to a comdat section. If I'm wrong on this, please try to explain. Jakub