From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 9E6B7DE62C for ; Wed, 23 Jul 2008 03:27:39 +1000 (EST) In-Reply-To: <18565.32839.382335.638503@cargo.ozlabs.ibm.com> References: <20080717183339.GA25070@in.ibm.com> <20080717184055.GB25070@in.ibm.com> <1216325187.7740.353.camel@pasglop> <48802AE0.30105@in.ibm.com> <4884E2E9.6050108@in.ibm.com> <18565.16369.993585.334427@cargo.ozlabs.ibm.com> <48856403.5050207@in.ibm.com> <18565.32839.382335.638503@cargo.ozlabs.ibm.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: From: Segher Boessenkool Subject: Re: [RFC v3 PATCH 6/4] Use LOAD_REG_IMMEDIATE macros Date: Tue, 22 Jul 2008 19:13:10 +0200 To: Paul Mackerras Cc: ppcdev , naren@linux.vnet.ibm.com, Milton Miller List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , >> All of the variables references through @got translated into >> relocation >> type R_PPC64_GOT16_DS entries. All these entries correspond to one of >> the above entries in the .got section. But none of the entries in .got >> section are relocated. > > If that last statement is really true, then that would be an absolute > show-stopper, since you're not going to stop the compiler generating > loads from the TOC to get addresses of things. > > However, I don't think it's true. I compiled up a kernel using > --emit-relocs on the final link, and with readelf -e I can see a > .rela.got section containing a bunch of R_PPC64_ADDR64 relocs for > entries in the .got section. > > So the problem appears to be either just that you are ignoring > R_PPC64_ADDR64 relocs, or else that your relocs.c program has a bug > and isn't seeing the .rela.got section. I analysed this further. .rela.got does have lots of relocs in it, but _not_ for relocations create with @got in the assembler code. GCC never does this AFAICS, it explicitly creates a TOC entry and uses that. So, the workaround would be to manually create TOC entries in the LOAD_REG_ADDR code as well. I'll work on that, feel free to beat me to it of course. >> Now I have two options left: >> 1. Check for R_PPC64_GOT16_DS entries and check whether the contents >> addressed by r2+offset is relocated or not and apply relocation if >> its not. >> 2. Change all LOAD_REG_ADDR macros to LOAD_REG_IMMEDIATE. This I have >> already done. > > I was trying to point out that this can't possibly be a viable > solution to the problem, because most of the TOC loads in the binary > are generated by the C compiler, and only a few of them come from use > of the LOAD_REG_ADDR macro in assembly code. binutils has a problem only with the @gotXXX relocations, where the _linker_ creates the GOT entry (it doesn't emit a reloc for -emit-relocs in that case). Segher