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 0997E385840C for ; Fri, 28 Jan 2022 17:48:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0997E385840C Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 20SFogsU030269 for ; Fri, 28 Jan 2022 17:48:50 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3dvh61wm33-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 28 Jan 2022 17:48:50 +0000 Received: from m0098394.ppops.net (m0098394.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 20SGlkh3031030 for ; Fri, 28 Jan 2022 17:48:49 GMT Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com with ESMTP id 3dvh61wm2y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Jan 2022 17:48:49 +0000 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 20SHW4VO016311; Fri, 28 Jan 2022 17:48:49 GMT Received: from b01cxnp23032.gho.pok.ibm.com (b01cxnp23032.gho.pok.ibm.com [9.57.198.27]) by ppma03dal.us.ibm.com with ESMTP id 3dr9jdn2y3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Jan 2022 17:48:49 +0000 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp23032.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 20SHmj9x27591058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 28 Jan 2022 17:48:45 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C1520B206C; Fri, 28 Jan 2022 17:48:45 +0000 (GMT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0267FB2073; Fri, 28 Jan 2022 17:48:44 +0000 (GMT) Received: from [9.65.220.149] (unknown [9.65.220.149]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP; Fri, 28 Jan 2022 17:48:44 +0000 (GMT) Message-ID: <5a44c0d1-9cbd-aac8-e60a-3627e58b023b@linux.ibm.com> Date: Fri, 28 Jan 2022 11:48:44 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [PowerPC64] Use medium model toc accesses throughout Content-Language: en-US To: Alan Modra , libc-alpha@sourceware.org Cc: Tulio Magno Quites Machado Filho References: From: Paul E Murphy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: MLzRNn9TJU4lwdMvhd3qJSWA2AA5eeju X-Proofpoint-ORIG-GUID: LAwUdV_YNzNKDGcPy_6c-B3NPO5e_zZM X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-01-28_05,2022-01-28_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 lowpriorityscore=0 malwarescore=0 adultscore=0 impostorscore=0 suspectscore=0 spamscore=0 priorityscore=1501 mlxscore=0 clxscore=1015 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2201280106 X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 17:48:53 -0000 On 1/23/22 6:42 AM, Alan Modra via Libc-alpha wrote: > The PowerPC64 linker edits medium model toc-indirect code to toc-pointer > relative: > addis r9,r2,tc_entry_for_var@toc@ha > ld r9,tc_entry_for_var@toc@l(r9) > becomes > addis r9,r2,(var-.TOC.)@ha > addi r9,r9,(var-.TOC.)@l > when "var" is known to be local to the binary. This isn't done for > small-model toc-indirect code, because "var" is almost guaranteed to > be too far away from .TOC. for a 16-bit signed offset. And, because > the analysis of which .toc entry can be removed becomes much more > complicated in objects that mix code models, they aren't removed if > any small-model toc sequence appears in an object file. > > Unfortunately glibc's build of ld.so smashes the needed objects > together in a ld -r linking stage. This means the GOT/TOC is left > with a whole lot of relative relocations which is untidy, but in > itself is not a serious problem. However, static-pie on powerpc64 > bombs due to a segfault caused by one of the small-model accesses > before _dl_relocate_static_pie. (The very first one in rcrt1.o > passing start_addresses in r8 to __libc_start_main.) > > So this patch makes all the toc/got accesses in assembly medium code > model, and a couple of functions hidden. By itself this is *not* > enough to give us working static-pie, but it is useful anyway to > enable better linker optimisation. > > There's a serious problem in libgcc too. libgcc ifuncs access the > AT_HWCAP words stored in the tcb with an offset from the thread > pointer (r13), but r13 isn't set at the time _dl_relocate_static_pie > runs, and I'm loathe to try calling init_tls early. A better approach > that might work is to fake r13 so that _dl_hwcap is at the expected > offset where we'd normally find the tcb hwcap words. > > Tested for regressions with a powerpc64le-linux build and test run. > OK to apply? > > diff --git a/sysdeps/powerpc/powerpc64/dl-trampoline.S b/sysdeps/powerpc/powerpc64/dl-trampoline.S > index 23debc2faf..45b821607b 100644 > --- a/sysdeps/powerpc/powerpc64/dl-trampoline.S > +++ b/sysdeps/powerpc/powerpc64/dl-trampoline.S > @@ -32,6 +32,7 @@ > because gcc as of 2010/05 doesn't allocate a proper stack frame for > a function that makes no calls except for __tls_get_addr and we > might be here resolving the __tls_get_addr call. */ > + .hidden _dl_runtime_resolve > #define INT_PARMS FRAME_MIN_SIZE > ENTRY (_dl_runtime_resolve, 4) > stdu r1,-FRAME_SIZE(r1) > @@ -195,6 +196,7 @@ END(_dl_runtime_resolve) > parm1 (r3) and the index (r0) needs to be converted to an offset > (index * 24) in parm2 (r4). */ > #ifndef PROF > + .hidden _dl_profile_resolve > ENTRY (_dl_profile_resolve, 4) > /* Spill r30, r31 to preserve the link_map* and reloc_addr, in case we > need to call _dl_audit_pltexit. */ LGTM (this should wait until after the freeze), though these two changes seem orthogonal to the commit title. For my education, why are are small model accesses used in these files?