Glen Kriekenbeck wrote:
> 2. Also, the formulas in Linker and Libraries guide seem to be misleading.
> For reloc types R_SPARC_GOTDATA_LOX22 and R_SPARC_GOTDATA_OP_LOX22
> it says:
>
> ((S+A-GOT) >> 10) & 0x3ff) | (0x1c00 ^~ (((S+A-GOT) >> 50) & 0x1c00)).
Ok, relocations aren't my strong point, and Mike (who could read all this
gibberish in his sleep) is no longer a linker engineer. But I looked at
the L&LM definitions, the comments in doreloc.c, and the original ARC case
(PSARC/2003/477) and there's certainly a lot of inconsistency. However,
Mike (now acting in a consulting capacity) kindly poked around the
implementation details and believes these reflect the calculations actually
being carried out:
R_SPARC_GOTDATA_HIX22 80 T-imm22
((S + A - GOT) >> 10) ^ ((S + A - GOT) >> 31)
R_SPARC_GOTDATA_LOX10 81 T-imm13
((S + A - GOT) & 0x3ff) | (((S + A - GOT) >> 31) & 0x1c00)
R_SPARC_GOTDATA_OP_HIX22 82 T-imm22
(G >> 10) ^ (G >> 31)
R_SPARC_GOTDATA_OP_LOX10 83 T-imm13
(G & 0x3ff) | ((G >> 31) & 0x1c00)
The ARC case got it wrong in that it used 'G' to represent two things.
The 'G' is defined to be the offset into the Global Offset Table. What we
really wanted instead for the first two is the offset from the beginning of the
global offset table (which is S + A - GOT).
The added twist is that the R_SPARC_GOTDATA_OP* relocation meaning changes if
they are binding to local symbols. In that case they use the first formulas
((S+A-G)) and then the R_SPARC_GOTDATA_OP instruction get's a fixup.
Hopefully this, and the ARC material will give you the details you need.
Also, there's a couple of compiler folks lurking on this alias who I also
believe were deeply involved with these relocations, so unless we hear
differently, I'll assume they agree with the above definitions.
I'll get the L&LM updated to reflect the correct definitions.
--
Rod.
