linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Mohan Kumar M <mohan@in.ibm.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: ppcdev <linuxppc-dev@ozlabs.org>, paulus@samba.org, miltonm@bga.com
Subject: Re: [RFC v3 PATCH 4/4] Relocation support
Date: Mon, 21 Jul 2008 14:41:37 +0530	[thread overview]
Message-ID: <488452C9.6050408@in.ibm.com> (raw)
In-Reply-To: <5bcb241a0597d5d23724c653e9c9b4eb@kernel.crashing.org>

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.


<Snip objdump of 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.

      reply	other threads:[~2008-07-21  9:12 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-17 18:33 [RFC v3 PATCH 0/4] Relocatable kernel support for PPC64 Mohan Kumar M
2008-07-17 18:40 ` [RFC v3 PATCH 1/4] Extract list of relocation offsets Mohan Kumar M
2008-07-17 20:06   ` Benjamin Herrenschmidt
2008-07-18  5:32     ` Mohan Kumar M
2008-07-18 17:00       ` Milton Miller
2008-07-21 19:17         ` Mohan Kumar M
2008-07-22  6:29           ` Paul Mackerras
2008-07-22  7:58             ` Mohan Kumar M
2008-07-21 19:20         ` [RFC v3 PATCH 2/4] Build files needed for relocation Mohan Kumar M
2008-07-21 19:21         ` [RFC v3 PATCH 3/4] Apply relocation Mohan Kumar M
2008-07-21 19:23         ` [RFC v3 PATCH 4/4] Relocation support Mohan Kumar M
2008-07-21 19:25         ` [RFC v3 PATCH 5/4] Relocation support for kdump kernel Mohan Kumar M
2008-07-21 19:26         ` [RFC v3 PATCH 6/4] Use LOAD_REG_IMMEDIATE macros Mohan Kumar M
2008-07-22  2:03           ` Paul Mackerras
2008-07-22  4:37             ` Mohan Kumar M
2008-07-22  6:37               ` Paul Mackerras
2008-07-22 17:13                 ` Segher Boessenkool
2008-07-17 18:42 ` [RFC v3 PATCH 2/4] Build files needed for relocation support Mohan Kumar M
2008-07-17 18:45 ` [RFC v3 PATCH 3/4] Apply relocation info to vmlinux Mohan Kumar M
2008-07-17 18:48 ` [RFC v3 PATCH 4/4] Relocation support Mohan Kumar M
2008-07-18 17:48   ` Segher Boessenkool
2008-07-21  9:11     ` Mohan Kumar M [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=488452C9.6050408@in.ibm.com \
    --to=mohan@in.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=miltonm@bga.com \
    --cc=paulus@samba.org \
    --cc=segher@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).