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::4]) by sourceware.org (Postfix) with ESMTP id BE6F53854835 for ; Fri, 19 Feb 2021 18:17:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BE6F53854835 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=macro@orcam.me.uk Received: by angie.orcam.me.uk (Postfix, from userid 500) id 2CAFF92009C; Fri, 19 Feb 2021 19:17:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 26FC592009B; Fri, 19 Feb 2021 19:17:08 +0100 (CET) Date: Fri, 19 Feb 2021 19:17:08 +0100 (CET) From: "Maciej W. Rozycki" To: Project Revolution cc: Andrew Pinski , "gcc@gcc.gnu.org" , "kenixwhisperwind@gmail.com" Subject: Re: GCC generates non-compliant MIPS relocation data? Obscure GNU extension? 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.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_INFOUSMEBIZ, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 18:17:11 -0000 On Fri, 19 Feb 2021, Project Revolution via Gcc wrote: > Gentlemen: this was fixed, although it's a bit of an odd solution. We > had to combine both -mno-explicit-relocs and -mno-split-addresses, even > though per the MIPS compiler documentation explicit relocs supersedes > the split addresses one. Neither of these options on their own work, and > it appears as though they're same result individually until you enable > both of these. It's really odd, but we're not questioning it since it > resolved our issue. The GNU extension that permits multiple R_MIPS_HI16 relocations to be matched with one R_MIPS_LO16 relocation for the ABIs such as o32 that use the REL relocation format lets the compiler make optimisations that would otherwise not be possible. A typical use case is moving a LUI instruction targetted by multiple branches into the respective delay slots, resulting in overall shrinking of code by one instruction, such as transforming this (delay-slot instructions conventionally indented by one space): .set noreorder # ... beq $2, $3, $L16 nop # ... $L16: lui $4, %hi(foo) lw $5, %lo(foo)($4) # ... bltz $4, $L16 nop into this: .set noreorder # ... beq $2, $3, $L16 lui $4, %hi(foo) # ... $L16: lw $5, %lo(foo)($4) # ... bltz $4, $L16 lui $4, %hi(foo) (depending on the execution flow, optimisation options and the ISA level chosen branch-likely instructions might be used instead). I agree the outcome of the years of MIPS psABI development reflected in what GCC and GNU binutils produce nowadays hasn't been properly documented and sources of information may be scarce. The original SVR4 MIPS psABI document has had its issues and I believe no exact implementation exists, including though not limited to SGI IRIX. That said attempts were made in the past to document the state of affairs and here's one kept by archive.org that actually mentions the feature: . The original has been lost however in the turbulent history of the various MIPS companies. I'm glad to hear you have found a usable workaround. Otherwise I think we might consider adding an option to GCC to disable this psABI extension, however offhand I am not sure how difficult it would be to implement. It looks to me however that you actually have control over the relocation processing code you have referred, so how about improving it to handle the GNU R_MIPS_HI16 extension as well? It should be straightforward as proved by the usual consumers of MIPS object code, such as the GNU linker, the Linux kernel module loader, etc. It should give you a smaller code footprint too, to say nothing of the size regression the use of `-mno-explicit-relocs' usually results in. Have you considered it? Maciej