From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id F27E73858D20 for ; Fri, 4 Feb 2022 20:12:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F27E73858D20 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: QRTuvoDvDDzZ90+vpPh0yvkSfd99ZARDgmXkYZAHWuGrz5yJxlCyXYSDZyaSS3KoDEUBFpWYBf bKB4IpgN48aEZnFum4IRe2xieDpil95AtFsaJHTH7qvyZPdYShnjAbsQ7UXywQRcTPpa1VkOTC zcdgKFNxWYIRfbpi+tOPiNF7pE1ySZmDtLnMcAzOjsmTWyZw2yBZCPbp8P3BBwKGFKDiij8Hpm IsX2A2e9WvFDo65iCOjy10f2LxCpx2mqRk1YMwPD5S0jQGiYDWnU/+joT415doYsYabEfK+jmw VCWV5QkERYvFFdZKe+UieOgi X-IronPort-AV: E=Sophos;i="5.88,343,1635235200"; d="scan'208";a="74157744" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 04 Feb 2022 12:12:42 -0800 IronPort-SDR: OPdN4D6jhttHEtY97Tvkk3Js2kDgy/VnzHmowpux/7MAJJDeZu05zyYww/VjhDLnWkGHYcEp2/ Q2AESmLuTxk3VTHh2tJo0Vhj4G0fVuW4Ljjglnqt3tWUfSRYc4LZ6AS16wzTEoUMOJhD0WFseH qUHJ2KFFYUv2L+PgjgjdVSFtqz9SBlaz1X4vvm2dua7gNMIiKyVuiy0WUFRPQMQeUieh5PGhXe w4PDxKtCgiguS2v7l9nD+Oxl5dlr4pRBIgp106J0UrJr3ppg3bQhZRao/5dwlMu6oq2gNF7gGV 5tI= Date: Fri, 4 Feb 2022 20:12:36 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: "H.J. Lu" CC: GNU C Library Subject: Re: [PATCH 0/7] Support DT_RELR relative relocation format In-Reply-To: Message-ID: References: <20220203180948.2744-1-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 20:12:44 -0000 On Fri, 4 Feb 2022, H.J. Lu via Libc-alpha wrote: > On Fri, Feb 4, 2022 at 12:00 PM Joseph Myers wrote: > > > > On Thu, 3 Feb 2022, H.J. Lu via Libc-alpha wrote: > > > > > DT_RELR is enabled in glibc shared libraries and position independent > > > executables (PIE) automatically if linker supports -z pack-relative-relocs > > > nd the architecture defines SUPPORT_DT_RELR in config.h. At the moment, > > > only x86 targets define SUPPORT_DT_RELR. > > > > The patch 1 description says "This patch is simpler than Chrome OS's glibc > > patch and makes ELF_DYNAMIC_DO_RELR available to all ports.". > > > > What exactly would other architectures need to add in glibc to provide > > RELR support, since I don't see any actual architecture-specific code in > > DT_RELR is enabled only if linker supports -z report-relative-reloc option > which adds GLIBC_ABI_DT_RELR dependency in the linker output to > prevent random crashes with the older glibc binaries. What do you mean by "is enabled"? Building glibc itself to use such relocations can properly depend on linker support. The set of binaries (executables and shared libraries) glibc can load must not depend on linker support. Those are two different questions. -- Joseph S. Myers joseph@codesourcery.com