From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "e1.ny.us.ibm.com", Issuer "Equifax" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id EF06BDDECF for ; Mon, 21 Jul 2008 19:12:16 +1000 (EST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6L9BxXY010333 for ; Mon, 21 Jul 2008 05:11:59 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6L9Bxom186464 for ; Mon, 21 Jul 2008 05:11:59 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6L9Bwi9012519 for ; Mon, 21 Jul 2008 05:11:58 -0400 Message-ID: <488452C9.6050408@in.ibm.com> Date: Mon, 21 Jul 2008 14:41:37 +0530 From: Mohan Kumar M MIME-Version: 1.0 To: Segher Boessenkool Subject: Re: [RFC v3 PATCH 4/4] Relocation support References: <20080717183339.GA25070@in.ibm.com> <20080717184843.GE25070@in.ibm.com> <5bcb241a0597d5d23724c653e9c9b4eb@kernel.crashing.org> In-Reply-To: <5bcb241a0597d5d23724c653e9c9b4eb@kernel.crashing.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Cc: ppcdev , paulus@samba.org, miltonm@bga.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Segher Boessenkool wrote: >> This patch changes all LOAD_REG_ADDR macro calls to LOAD_REG_IMMEDIATE >> to make sure that we load the correct address. > > Did you figure out _why_ LOAD_REG_ADDR doesn't work? Using > LOAD_REG_IMMEDIATE is actually a step back, it makes the kernel > binary non-PIC. And LOAD_REG_ADDR _should_ work just fine with > your scheme. > Hi Segher, I was going through the output generated by objdump -D vmlinux and readelf -h vmlinux. Disassembly of section .got: c000000000805010 <__toc_start>: c000000000805010: c0 00 00 00 lfs f0,0(0) c000000000805014: 00 80 d0 10 .long 0x80d010 c000000000805018: c0 00 00 00 lfs f0,0(0) c00000000080501c: 00 00 83 58 .long 0x8358 c000000000805020: c0 00 00 00 lfs f0,0(0) c000000000805024: 00 85 1f e8 .long 0x851fe8 c000000000805028: c0 00 00 00 lfs f0,0(0) c00000000080502c: 00 00 8d 84 .long 0x8d84 c000000000805030: c0 00 00 00 lfs f0,0(0) c000000000805034: 00 85 03 38 .long 0x850338 c000000000805038: c0 00 00 00 lfs f0,0(0) c00000000080503c: 00 85 28 b8 .long 0x8528b8 c000000000805040: c0 00 00 00 lfs f0,0(0) c000000000805044: 00 85 28 b0 .long 0x8528b0 c000000000805048: c0 00 00 00 lfs f0,0(0) c00000000080504c: 00 6d ef 60 .long 0x6def60 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. For example the instruction with relocation type R_PPC64_GOT16_DS, c00000000000830c: e8 62 80 10 ld r3,-32752(r2) refers to current_set variable. r2 will be pointing to 0xc00000000280d010 (relocated __toc_start + 0x8000). So the instruction loads r3 with the content 0xc000000000851fe8 at location 0xc000000002805020, but which is not a relocated entry (0xc000000000851fe8) But when there is a relocation type of R_PPC64_ADDR16_HI, like c000000000008110: 64 84 00 00 oris r4,r4,0 we could easily get more info about this relocation from readelf like: c000000000008112 000100000005 R_PPC64_ADDR16_HI c000000000000000 .text + 8124 So from above output we can identify that instruction at address c000000000008112 needs to be patched with the relocation delta. 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. Regards, Mohan.