Eliminating R_PPC_REL32 relocations

[Joshua N. Edmison]

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