From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34]) by sourceware.org (Postfix) with ESMTP id 98F70385829F for ; Fri, 5 Aug 2022 15:13:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 98F70385829F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk Received: by angie.orcam.me.uk (Postfix, from userid 500) id E379692009D; Fri, 5 Aug 2022 17:13:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id DF7D592009C; Fri, 5 Aug 2022 16:13:07 +0100 (BST) Date: Fri, 5 Aug 2022 16:13:07 +0100 (BST) From: "Maciej W. Rozycki" To: Alan Modra cc: binutils@sourceware.org Subject: Re: BFD_RELOC_MIPS_16 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3488.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_INFOUSMEBIZ, KAM_LAZY_DOMAIN_SECURITY, KAM_NUMSUBJECT, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2022 15:13:11 -0000 On Thu, 4 Aug 2022, Alan Modra wrote: > > > time. Like BFD_RELOC_8, BFD_RELOC_16 now has no corresponding object > > > file relocation, and thus .half, .hword, .short and .dc.w must be > > > resolved at assembly time. > > > > That should be R_MIPS_REL16 AFAICT, reloc #33 according to MIPS NewABI > > documentation[1]: > > > > Name Value Field Symbol Calculation > > R_MIPS_REL16 33 V-hw16 any S+A > > Huh. So R_MIPS_REL16 isn't a pc-relative reloc as the name might > indicate. I'll apply the following. It's not clear to me what the REL infix might imply here given how other relevant relocations have been defined: Name Value Field Symbol Calculation R_MIPS_16 1 V-half16 any S+sign_extend(A) R_MIPS_REL32 3 T-word32 any S+A-EA R_MIPS_PC16 10 V-pc16 any sign_extend(A)+S-P but the calculation given is I believe unambiguous and refers neither EA (effective address; meaningful for dynamic loading only and referring to factoring the base address into the calculation) nor P (PC). Of course I cannot claim the document is flawless; even the definition of R_MIPS_16 carried over from the old ABI isn't right anymore given that NewABI has RELA relocations. Maybe IRIX actually implemented R_MIPS_REL16 in a different manner. I have no means to verify that however, so the document is the best resource we have. Last but not least please note that NewABI makes heavy use of composed relocations, so R_MIPS_REL16 may have just been a way to specify a 16-bit relocatable field, useful for compact jump tables for example, especially given the relocation's straightforward calculation, and R_MIPS_16 had already been taken so a different name had to be come up with. Then you can compose R_MIPS_PC16 with R_MIPS_REL16 to make a PC-relative 16-bit relocatable field, similarly to how say a 64-bit base-address-relative relocatable field is made by composing R_MIPS_REL32 (alias R_MIPS_REL) with R_MIPS_64. The latter operation is documented in the specification referred as are a couple of other ones[1]: "The initial elf.h file defined several relocations for dealing with GOTs larger than 64KB which we do not include, favoring other approaches as described above: " R_MIPS_REL64 This can be produced by composing R_MIPS_REL with R_MIPS_64. " R_MIPS_LIT_HI16, R_MIPS_LIT_LO16 These can be produced by composing R_MIPS_LITERAL with R_MIPS_HI16 or R_MIPS_LO16. " R_MIPS_GPOFF_HI16, R_MIPS_GPOFF_LO16 As described above, these can be produced by composing R_MIPS_GPREL with R_MIPS_HI16 or R_MIPS_LO16." but the list is by no means exhaustive given that relocation composition is a generic ELF feature (even is scarcely implemented). So I'm now quite convinced the calculation is right and only the name of the relocation misleading. > * elf64-mips.c (mips_reloc_map): Map BFD_RELOC_16 to R_MIPS_REL16. > * elfn32-mips.c (mips_reloc_map): Likewise. LGTM, thanks! References: [1] "64-bit ELF Object File Specification", Draft Version 2.5, MIPS Technologies / Silicon Graphics Computer Systems, Document Number 007-4658-001, Section 2.9.4 "Discarded Relocations", pp. 52-53 Maciej