From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99458 invoked by alias); 28 Jun 2018 14:54:00 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 98428 invoked by uid 89); 28 Jun 2018 14:53:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=gained, gpl, extraction X-HELO: 9pmail.ess.barracuda.com Date: Thu, 28 Jun 2018 14:54:00 -0000 From: "Maciej W. Rozycki" To: Florian Weimer CC: , Alan Modra Subject: Re: [PATCH 2/2] libc-abis: Define ABSOLUTE ABI [BZ #19818][BZ #23307] In-Reply-To: Message-ID: References: <87sh5a38tz.fsf@mid.deneb.enyo.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-Path: macro@mips.com X-BESS-Apparent-Source-IP: 12.201.5.32 X-SW-Source: 2018-06/txt/msg00901.txt.bz2 On Thu, 28 Jun 2018, Florian Weimer wrote: > On 06/28/2018 03:49 PM, Maciej W. Rozycki wrote: > > + /* Mark that we need support for absolute symbols in the dynamic loader. > > */ > > + if (htab != NULL && htab->use_absolute_zero) > > + i_ehdrp->e_ident[EI_ABIVERSION] = MIPS_LIBC_ABI_ABSOLUTE; > > + > > _bfd_elf_post_process_headers (abfd, link_info); > > } > > and then `htab->use_absolute_zero' will be TRUE iff a GOT relocation has > > been calculated to actually refer to a specially-created absolute symbol > > used to address the issue covered by binutils PR ld/21375. > > > > The flag will be FALSE if code has been relaxed to avoid referring the > > GOT (by using immediate zero instead), in which case no absolute symbol > > will have been specially created. > > > > Does this explanation clear your concern? > > Yes, I think this is okay then. Great! > We cannot express this change at the RPM dependency level, but I'm not sure > how active the Fedora MIPS port is these days, so it probably does not matter. The case of MIPS_LIBC_ABI_ABSOLUTE is supposed to be exceedingly rare. However I decided to handle it, rather than having the linker fail, be it with an assertion failure or gracefully. I think RPM could be easily expanded to include EI_ABIVERSION with its existing dependency mechanism. The EI_ABIVERSION field is reported by `readelf -h', so the requirement could be easily extracted from binaries just like symbol versioning information is. The only complication is the package supplying the dynamic loader, where the provision of the maximum value of EI_ABIVERSION supported would I think have to be entered manually in the package spec. Decades ago I modified the RPM dependency extraction scripts (`linux.req' and `linux.prov') to use `readelf' rather than a combination of `objdump' and `ldd' (although I left the latter as a fallback to keep supporting a.out dependencies), so that dependencies were right for cross-compiled packages. I have never submitted that work back (as I recall it was not exactly easy to get through), however experience gained with that makes me think expanding the mechanism to include EI_ABIVERSION should be straightforward to implement. Perhaps it would be worth doing anyway, just in case? NB I have no idea what RPM uses these days for dependency tracking and whether it handles cross-compilation right or not. Work I did back then remains available from `ftp.linux-mips.org', in the form of RPM 3.0.6 RPM packages; the GNU GPL applies. Maciej