This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.
>
>  
>





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]