From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id B0E493858C66 for ; Tue, 22 Nov 2022 02:58:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B0E493858C66 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2AM1VVIn026294; Tue, 22 Nov 2022 02:58:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : references : cc : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=OUykQ+0SkKWWoggr22ca3vGqz5zqfCF/G8FGybbfcSg=; b=gIQPPBZBZx4ntpii+xZiv4rhtKvPNmkXfRvMx4DFXbGmJLE3Dt/oN+/P14gqjAcUE3dX ByOwOaOtyb/QU1VZgfyoAShvuFpzpnXI+0F4IXRbYvlE5Fw130imvutjs+5D8DDvTU4m LsnL2mKQhRIKx2FeUELdgeQeCNF5jBL2apnVWm5QaGDp0BqG/6jzOpwOtNc2GOoBAf9f TsCblDcDNUiVLvSw5GnzfEpqckrThQKwkWDuAriUTqwIIJmi2vjkbvQVQIKAI2cgSLqC f5FrVfW5PkbKaARDFSBmAgduqa7K7ra1K7DfToNeKaG59FOd+8jHhYDE6jEmqHiausdf TA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3m0mu7hgbd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Nov 2022 02:58:15 +0000 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2AM2vN9u022645; Tue, 22 Nov 2022 02:58:15 GMT Received: from ppma04ams.nl.ibm.com (63.31.33a9.ip4.static.sl-reverse.com [169.51.49.99]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3m0mu7hgaq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Nov 2022 02:58:15 +0000 Received: from pps.filterd (ppma04ams.nl.ibm.com [127.0.0.1]) by ppma04ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 2AM2p6Qv014698; Tue, 22 Nov 2022 02:58:12 GMT Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by ppma04ams.nl.ibm.com with ESMTP id 3kxps8ufdn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Nov 2022 02:58:12 +0000 Received: from d06av24.portsmouth.uk.ibm.com (mk.ibm.com [9.149.105.60]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2AM2wAgZ1638940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 22 Nov 2022 02:58:10 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1E0B742041; Tue, 22 Nov 2022 02:58:10 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7449D4203F; Tue, 22 Nov 2022 02:58:06 +0000 (GMT) Received: from [9.200.45.208] (unknown [9.200.45.208]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 22 Nov 2022 02:58:06 +0000 (GMT) Message-ID: Date: Tue, 22 Nov 2022 10:58:04 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: PING^2 [PATCH] Adjust the symbol for SECTION_LINK_ORDER linked_to section [PR99889] Content-Language: en-US To: richard.sandiford@arm.com References: <0558633c-b553-5ef1-aa6f-c76fcf297454@linux.ibm.com> <52ca56ad-af0f-598f-4ccf-aed61fce67b4@linux.ibm.com> <15b488a5-1f5e-c24e-be12-f402b0dcdb5e@linux.ibm.com> Cc: GCC Patches , Jakub Jelinek , Segher Boessenkool , Peter Bergner , jlaw@ventanamicro.com, AlanM , David Edelsohn , Richard Biener , "H.J. Lu" From: "Kewen.Lin" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: BKN2q43zzRsKv5pmGxb70uXRa4mtV3fw X-Proofpoint-ORIG-GUID: HihjQ5EFQN5fmWGsxEGgSbvJ1JuTLpNb X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-21_18,2022-11-18_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 malwarescore=0 spamscore=0 impostorscore=0 suspectscore=0 adultscore=0 clxscore=1015 lowpriorityscore=0 priorityscore=1501 mlxscore=0 bulkscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211220015 X-Spam-Status: No, score=-11.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP 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: Hi Richard, Many thanks for your review comments! >>> on 2022/8/24 16:17, Kewen.Lin via Gcc-patches wrote: >>>> Hi, >>>> >>>> As discussed in PR98125, -fpatchable-function-entry with >>>> SECTION_LINK_ORDER support doesn't work well on powerpc64 >>>> ELFv1 because the filled "Symbol" in >>>> >>>> .section name,"flags"o,@type,Symbol >>>> >>>> sits in .opd section instead of in the function_section >>>> like .text or named .text*. >>>> >>>> Since we already generates one label LPFE* which sits in >>>> function_section of current_function_decl, this patch is >>>> to reuse it as the symbol for the linked_to section. It >>>> avoids the above ABI specific issue when using the symbol >>>> concluded from current_function_decl. >>>> >>>> Besides, with this support some previous workarounds for >>>> powerpc64 ELFv1 can be reverted. >>>> >>>> btw, rs6000_print_patchable_function_entry can be dropped >>>> but there is another rs6000 patch which needs this rs6000 >>>> specific hook rs6000_print_patchable_function_entry, not >>>> sure which one gets landed first, so just leave it here. >>>> >>>> Bootstrapped and regtested on below: >>>> >>>> 1) powerpc64-linux-gnu P8 with default binutils 2.27 >>>> and latest binutils 2.39. >>>> 2) powerpc64le-linux-gnu P9 (default binutils 2.30). >>>> 3) powerpc64le-linux-gnu P10 (default binutils 2.30). >>>> 4) x86_64-redhat-linux with default binutils 2.30 >>>> and latest binutils 2.39. >>>> 5) aarch64-linux-gnu with default binutils 2.30 >>>> and latest binutils 2.39. >>>> [snip...] >>>> diff --git a/gcc/varasm.cc b/gcc/varasm.cc >>>> index 4db8506b106..d4de6e164ee 100644 >>>> --- a/gcc/varasm.cc >>>> +++ b/gcc/varasm.cc >>>> @@ -6906,11 +6906,16 @@ default_elf_asm_named_section (const char *name, unsigned int flags, >>>> fprintf (asm_out_file, ",%d", flags & SECTION_ENTSIZE); >>>> if (flags & SECTION_LINK_ORDER) >>>> { >>>> - tree id = DECL_ASSEMBLER_NAME (decl); >>>> - ultimate_transparent_alias_target (&id); >>>> - const char *name = IDENTIFIER_POINTER (id); >>>> - name = targetm.strip_name_encoding (name); >>>> - fprintf (asm_out_file, ",%s", name); >>>> + /* For now, only section "__patchable_function_entries" >>>> + adopts flag SECTION_LINK_ORDER, internal label LPFE* >>>> + was emitted in default_print_patchable_function_entry, >>>> + just place it here for linked_to section. */ >>>> + gcc_assert (!strcmp (name, "__patchable_function_entries")); > > I like the idea of removing the rs600 workaround in favour of making the > target-independent more robust. But this seems a bit hackish. What > would we do if SECTION_LINK_ORDER was used for something else in future? > Good question! I think it depends on how we can get the symbol for the linked_to section, if adopting the name of the decl will suffer the similar issue which this patch wants to fix, we have to reuse the label LPFE* or some kind of new artificial label in the related section; or we can just go with the name of the given decl, or something related to that decl. Since we can't predict any future uses, I just placed an assertion here to ensure that we would revisit and adjust this part at that time. Does it sound reasonable to you? BR, Kewen