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 B78CD3858416 for ; Wed, 31 Jan 2024 18:11:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B78CD3858416 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 B78CD3858416 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=1706724690; cv=none; b=MJ0MAyUoBT5AQKuPbDu4nbGMIgQdVvsEMAFUt0RforXP2S/KMgpwfFHZ/CkoNDcUb/XRbxGzRmggKEgGtIE2viLhlvWDsWr77W1SWxtdLlMZhkmTOo9tpzCZUvFb3D2Z8bnnko5yrLeA/3zxkwfsf4YXuVgKvCRrwcVjnLutlbw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706724690; c=relaxed/simple; bh=anR2HvAj7ZJzSjDm375O+5jSb7z49kR9HEe/P5+E7h0=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=vHaI7lUbbdx/9NFqogK4kBE85+gaDIwl2e28LtfCU0QqpZ0CwA0uYOGtVV7ze+YlgJ35aI3lNMX5qgUgFRC1dAzXjOnUE81IvhXK/kj9xipqxy7+EAKOVkMRYX/F20mFQ/IlAM4D3Q8LWr/TJ8KoldRVkKyRoG+m35txKWJbSHk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1706724688; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=R+coAEyg8hzdIJOrKNhHv8xdyuGHIU6wTqxCTgc9xCw=; b=NZV+FZ6gPKP8KlCu1VnT4UZX1Kw7uPx4DOskCrVN8gw2/weS2u+S2+4WhAp+Oz8lAbPevU vHFXtW/q4HiAL5sI+dANB/8doOVRq5KKbrd67Kh84I0VDW1mJJlMZFN3mdM5zXNPJpklPx s9OC3Hpj9Xn0otYvTywsvcozqlBikl8= 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-651-U9gBw_m0PDWYpXitEuBRBQ-1; Wed, 31 Jan 2024 13:11:24 -0500 X-MC-Unique: U9gBw_m0PDWYpXitEuBRBQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (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 AF7C685A58B; Wed, 31 Jan 2024 18:11:23 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.70]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 726502166B33; Wed, 31 Jan 2024 18:11:23 +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 40VIBKjr293087 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 31 Jan 2024 19:11:21 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 40VIBKi0293086; Wed, 31 Jan 2024 19:11:20 +0100 Date: Wed, 31 Jan 2024 19:11:20 +0100 From: Jakub Jelinek To: "H.J. Lu" Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH v2] Handle private COMDAT function symbol reference in readonly data section Message-ID: Reply-To: Jakub Jelinek References: <20240131022136.572689-1-hjl.tools@gmail.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_STOCKGEN,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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 Wed, Jan 31, 2024 at 09:39:12AM -0800, H.J. Lu wrote: > GNU binutils has no issues with it: I know, I meant gcc. If I try the proposed: --- gcc/varasm.cc.jj 2024-01-30 08:44:43.304175273 +0100 +++ gcc/varasm.cc 2024-01-31 18:45:57.271087170 +0100 @@ -7459,15 +7459,46 @@ default_elf_select_rtx_section (machine_ { int reloc = compute_reloc_for_rtx (x); + tree decl = nullptr; + + /* If it is a private COMDAT function symbol reference, call + function_rodata_section for the read-only or relocated read-only + data section associated with function DECL so that the COMDAT + section will be used for the private COMDAT function symbol. */ + if (HAVE_COMDAT_GROUP) + { + if (GET_CODE (x) == CONST + && GET_CODE (XEXP (x, 0)) == PLUS + && CONST_INT_P (XEXP (XEXP (x, 0), 1))) + x = XEXP (XEXP (x, 0), 0); + + if (GET_CODE (x) == SYMBOL_REF) + { + decl = SYMBOL_REF_DECL (x); + if (decl + && (TREE_CODE (decl) != FUNCTION_DECL + || !DECL_COMDAT_GROUP (decl) + || TREE_PUBLIC (decl))) + decl = nullptr; + } + } + /* ??? Handle small data here somehow. */ if (reloc & targetm.asm_out.reloc_rw_mask ()) { + if (decl) + return get_section (reloc == 1 + ? ".data.rel.ro.local" : ".data.rel.ro", + SECTION_WRITE | SECTION_RELRO | SECTION_LINKONCE, + decl); if (reloc == 1) return get_named_section (NULL, ".data.rel.ro.local", 1); else return get_named_section (NULL, ".data.rel.ro", 3); } + else if (decl) + return get_section (".rodata", SECTION_LINKONCE, decl); return mergeable_constant_section (mode, align, 0); } and append typedef unsigned long int VV __attribute__((vector_size (2 * sizeof (long)))); VV vv; __attribute__((noipa)) static void fn1 (void) {} __attribute__((noipa)) static void fn2 (void) {} void fn3 () { VV a = { (unsigned long) &fn1, (unsigned long) &fn2 }; vv = a; } to the first testcase (this is just to get a normal non-comdat .data.rel.ro.local section referencing non-comdat non-public syumbol), then I get the pr113617.C:19:1: error: section type conflict with ‘static bool R::B<_R(_A ...), _F>::F(R::H&, const R::H&, R::G) [with _R = void; _F = R::I, false>*, long long int, long long int, long long int))(void*, long long int, long long int, long long int)>; _A = {}]’ 19 | } | ^ In file included from pr113617.C:1: pr113617.h:21:15: note: ‘static bool R::B<_R(_A ...), _F>::F(R::H&, const R::H&, R::G) [with _R = void; _F = R::I, false>*, long long int, long long int, long long int))(void*, long long int, long long int, long long int)>; _A = {}]’ was declared here 21 | static bool F(H &, const H &, G) { return false; } | ^ I feared. So, it seems get_section handles section purely by name lookup and isn't prepared to deal with multiple different sections of the same name, but different comdat group. Thus, maybe at least temporarily we need to use unique section names here, say .data.rel.ro.local.pool. .data.rel.ro.pool. .rodata.pool. where would be the name of the comdat group, i.e. IDENTIFIER_POINTER (DECL_COMDAT_GROUP (decl)) Jakub