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 4E5F93858C2D for ; Fri, 4 Feb 2022 23:58:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4E5F93858C2D 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: YUTg+mK82wu4nzSiJ1bCG5X81LECdvz3VwjFxkTVz5y67YkWHZiqOFnoyoBXNu+F81gZ1fvNxP Tw+CAy1sOf4ZrjdUvgwA32NSQ9gbDP3QZPO7gXitUMADsYNELtyrjq+AJ/CSPpKNCOcf3+Oif7 f7TWW64gVs0/xplOEoit0IyVr5OGFAdcu8B7PWU9VWcfqd9Ryes4EsFgSYgEHl7BSjjWa6kiVX SIEJ36f6l2i6p54H1iw6FNnn5lREMfxJzyfywkQE5CfX4VwfG0FjJ1kS8RZUEBev/RT3MIYks0 9qqHxftYwvpOROhH+4zs22DE X-IronPort-AV: E=Sophos;i="5.88,344,1635235200"; d="scan'208";a="74162104" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 04 Feb 2022 15:58:10 -0800 IronPort-SDR: tlWhVO1M3Iek74RWIBBy/4O0j5YzvmfQDZxnIjU//rLfbs2fZozHem9+T6HYMeP4baw5fgPwbb /xEsn9uuFKaB3lYnNEiSO4c1h+WFDX8X+ScqHO8Yml56Ew0Th40jyAMmutbkGVgttJXw4OaoCI x1Y6dn+JRek4sJM5e1BouR57o+/ctT8vzTuMkxS1ruqk04eRzXqGGteWVMQjeernPAHXfRWk4S adcSRugMSxksy0R1eNq+/4gEiPW97XKEsZbpjT4b1Q89L4fg/3+ghrRWzJpCakBNyucQGPt2fu 6Jg= Date: Fri, 4 Feb 2022 23:58:05 +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-08.mgc.mentorg.com (139.181.222.8) 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 23:58:13 -0000 On Fri, 4 Feb 2022, H.J. Lu via Libc-alpha wrote: > On Fri, Feb 4, 2022 at 1:01 PM Joseph Myers wrote: > > > > 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. > > RELR is kind of like static PIE. Not all architectures support it. My understanding is that analogy only applies to the static linker, not to glibc itself - that the static linker needs architecture-specific code, but glibc doesn't (as evidenced by the lack of any architecture-specific non-configure changes in this patch series). > RELR should be enabled only if there is a linker which supports > -z pack-relative-relocs. (a) That should only apply to "enabled" in the sense of "glibc itself uses RELR relocations", not "glibc supports loading executables and shared libraries with such relocations". (b) The configure test for that should be architecture-independent, with no architecture-specific configure changes needed at all. -- Joseph S. Myers joseph@codesourcery.com