This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: Eliminating R_PPC_REL32 relocations
- From: "David Dunkle" <ddunkle at arxan dot com>
- To: "'Joshua N. Edmison'" <jedmison at vt dot edu>, <binutils at sourceware dot org>
- Cc: "'David Dunkle'" <ddunkle at arxan dot com>
- Date: Wed, 7 Dec 2005 15:50:24 -0800
- Subject: RE: Eliminating R_PPC_REL32 relocations
Hi,
I have found that these relocations are used to implement the jump tables
associated with switch statements as generated by GCC. The jump tables are
in data sections in the cases I have examined.
-David Dunkle
Arxan Technologies
-----Original Message-----
From: binutils-owner@sourceware.org [mailto:binutils-owner@sourceware.org]
On Behalf Of Joshua N. Edmison
Sent: Wednesday, December 07, 2005 2:59 PM
To: binutils@sourceware.org
Subject: Re: Eliminating R_PPC_REL32 relocations
Daniel,
My apologies for the somewhat nonsensical question. Let me provide more
detail. Without drowning you in minutia, I am experimenting with some
different memory architectures and would like to isolate instruction and
data accesses (Harvard architecture style). The R_PPC_REL32 relocations
that appear when I compile shared/dynamic libraries violate the separation I
am trying to achieve by placing data values (essentially jump addresses) in
the executable (.text, .fini, .init) segments. After some debugging and
assembly level tracing (and using information provided by the --emit-relocs
option), I found that these R_PPC_REL32 relocations marked all of the
instances where this issue occurs. (The emit_relocs option in .rel.text,
.rel.init, and .rel.fini sections in the ELF) These don't pop up when I
compile a standalone executable (static or one that uses shared/dynamic
libraries), which leads me to believe its related to position independent
code.
It seems that the data values that are being stored and referenced in the
.text section are used to calculate addresses to jump across the address
space. My initial thought on why this would be necessary is since some
portion of a 32 bit instruction is an opcode, the remaining bits are not
sufficient to span the entire address space using branches and whatnot. I
also thought that the addresses calculation might be an efficiency over
using chained branches/jumps.
My current knowledge/understanding of the relocation process is marginal, so
my initial question was more of a feeler than anything.
Thanks for any insight you can provide.
Josh
Daniel Jacobowitz wrote:
>On Tue, Dec 06, 2005 at 01:51:01PM -0500, Joshua N. Edmison wrote:
>
>
>>I would like to remove/eliminate R_PPC_REL32 relocations when
>>compiling shared/dynamic libraries for the PowerPC405. I currently
>>use the -fPIC option when compiling. Is this possible? If so, how?
>>
>>
>
>The question doesn't make any sense; perhaps you should explain what
>problem you're having, and why you want to do this.
>
>
>