From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id CEDC73858D20 for ; Fri, 4 Feb 2022 21:01:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CEDC73858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: FiJhacSCHliPPl5u7mDzFlzld+nlwhdqrg9fpwgC27kYaXqu/gkhZsaIAgEoH1MJttdhDhsPG+ cJXwMDvX7F8Ej/gTfibWv8wYPrPABDbIHxlX/C42K+KYgFE7YQ/PEei4ZWHUnfbR49gIiSuroL U83Jay00EDD8v3P65DhgFgHMeSYBB2IDFyxa5K/z6xqsBFtAvRUftfs6QoWWpSvzXaZx1PYalH 07HqMg1q0ruiHQK8BIJFUpKVcLs6vcxPVMKiSfads/ZpqxhnYGpUIeD8mUkzXXPkr9wmuwIWi+ PnzzJB1320ZP4BD4VNxVIL4l X-IronPort-AV: E=Sophos;i="5.88,343,1635235200"; d="scan'208";a="71580974" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 04 Feb 2022 13:01:17 -0800 IronPort-SDR: AqyemmuJN0BoiHxbE5w5KZ3u8sRHPClbkArQ3988BrKsusIGtyyAhJ9zbOmU4s3mTOMWwloXgk anE87/rEi789Jo91WRFJ02myoK0S7Kf72egplNRR6f7SdJHwVbZVb7/5QCPgBjHdpE2YRGnkTq +ol09RWQmmkWNN1FSt2mEFwwLrI0BOMENhDJX49ju7lY4hMI+jvC52A3dF84/rM4U2W2gIDUE6 2NL/+b+RCvVs6O5ok7PEzub/tP2SQL1hL3MGdbi9pPEUj/zkum1sX+j8tf/f+ajhd8q/YfOupo oNM= Date: Fri, 4 Feb 2022 21:01:12 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: "H.J. Lu" CC: GNU C Library Subject: Re: [PATCH 3/7] Add GLIBC_ABI_DT_RELR for DT_RELR support In-Reply-To: Message-ID: References: <20220203180948.2744-1-hjl.tools@gmail.com> <20220203180948.2744-4-hjl.tools@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3115.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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, 04 Feb 2022 21:01:20 -0000 On Fri, 4 Feb 2022, H.J. Lu via Libc-alpha wrote: > Good point. How about "enable DT_RELR only if SUPPORT_DT_RELR is > defined? Currently, only x86 defines SUPPORT_DT_RELR. My preference would be: 1. Support user executables and shared libraries with RELR relocations across all platforms, unconditionally. 2. Build glibc to use RELR relocations in its own executables and shared libraries based on an architecture-independent configure test for whether linker support is present. And avoid any architecture-specific conditional relating to RELR support in glibc completely. *If* it turns out to be hard to have a fully reliable architecture-independent configure test for linker support, and the architecture-independent test reports linker support to be present (in an actual binutils release, not just the development mainline) for an architecture where that support is in fact buggy and incomplete, then we might consider adding an architecture-specific test on that architecture to disable building glibc to use RELR relocations with the buggy linker version. That is, architecture-specific tests would only be to disable building glibc to use RELR relocations, not to enable it, and only when the bugs in linker support on that architecture can't readily be detected by an architecture-independent test. The default for all existing and future architectures would be to follow the results of the architecture-independent configure test. -- Joseph S. Myers joseph@codesourcery.com