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 946E83858C3A; Mon, 11 Oct 2021 22:08:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 946E83858C3A 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: jYI1/VH2gG++ZkP7GRftlL/bIAY9WEOAd3w5MXYUHbJGVGgoBmxu5skKyUszYeqAZ57gE0vDq4 Jbnxt6mhi9JdIsl0z6ZWa506Oy0H6d/pczPxWiQHSZU1RdO9DrK9hffoZCBdenUhBSnFIxrDM9 H5QdkLY5DaVbUd6mvegXbYf11hiWSy4l6Qc16runfTX0By+Bje1wT7YJPmGTA6HecchhS4T49N TgpRUdnQa1lBCfD40xPWF8M5OcM4G1Dt1Z0XwQmPzXYWw1BTkpyq44as2APL622W9TC1Q+vWya kN6f7DL/QdRAnz8Q5NmjT5S4 X-IronPort-AV: E=Sophos;i="5.85,365,1624348800"; d="scan'208";a="67080917" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 11 Oct 2021 14:08:56 -0800 IronPort-SDR: v+KsX6CRLDqJN1eoX4Rao08MscHw1rUHBhd5bKmhRuFFIJNTHGTGcuCg5gUZlkwyyPSrDFtZJs FYsZjGxNhtAHQtI5EUIkj3tm3orzgml4eGdgwfFVJKDQ5uR6Ghy8ADf6xxeGiXN3tl1DBZwVza Jg80fV+gZxGwQCByePOoFumeNjSIx2is+FN9KpQhm4C8hS+8He4nZy9SulOsuECUbhj96sKmHD eX58lreqySOac13cc7dDpQe0tILad+jHPiT4vS7xBvXWbwxwtgK7zRE8vNssT0afmIO/be34oF 2EI= Date: Mon, 11 Oct 2021 22:08:51 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: =?UTF-8?Q?F=C4=81ng-ru=C3=AC_S=C3=B2ng?= CC: Jan Beulich , , Subject: Re: [PATCH] elf: Support DT_RELR relative relocation format [BZ #27924] In-Reply-To: Message-ID: References: <20211008065740.1485737-1-maskray@google.com> <3368ef30-eb8c-8828-1af0-1a227d99dc93@suse.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3117.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Mon, 11 Oct 2021 22:08:58 -0000 On Mon, 11 Oct 2021, Fāng-ruì Sòng via Libc-alpha wrote: > > While in line with the proposed spec additions I'm afraid the uses of > > ElfW(Addr) here aren't universally correct: You assume that ELF > > container type (size) expresses an aspect of the ABI. While this is > > indeed the case for several arch-es, I think this has been a mistake. > > IA-64, while meanwhile mostly dead, is (was) an example where 64-bit > > code can validly live in a 32-bit ELF container (at least as far as > > the psABI is concerned; I have no idea whether glibc actually > > followed the spec). There's a separate ELF header flag indicating the > > ABI, and hence the size of a pointer. > > Thanks for chiming in. > > As of ia64 buildability, it works for me: As far as I know, glibc and the Linux kernel never supported ILP32 on ia64 (HP-UX did). But I'm not entirely clear whether the ILP32 ABI is what's being referred to here (cf. x32, MIPS n32, etc. - ILP32 ABIs using 64-bit instructions, and 32-bit ELF), or something else. -- Joseph S. Myers joseph@codesourcery.com