[PATCH] D30699: [ELF] - Stop producing broken output for R_386_GOT32X relocation.

[George Rimar via Phabricator via llvm-commits]

grimar added a comment.

In https://reviews.llvm.org/D30699#697084, @ruiu wrote:

> We do not rewrite instructions for GOT32X relocations, so I don't think we've implemented the optimization for GOT32X. In https://groups.google.com/forum/#!topic/ia32-abi/GbJJskkid4I, H.J. Lu said that GOT32X can be handled as GOT32 if the linker chose not to optimize the relocation. I'm little confused. What are you trying to resolve with this patch?


Yes, we do not optimize(rewrite) the instructions yet (I am working on a patch for this now, btw), so let me explain.
Optimizing this relocation and evaluating it is orthogonal things. We currently do not evaluate it properly.

There are 2 possible cases when relocation can be generated, example:
movl ifunc at GOT, %eax vs movl ifunc at GOT(%eax), %eax 
First one should be evaluated as G + A and so resolves to entry address in GOT (allowed for no-PIC only).
Second is evaluated to offset because address in runtime will be [eax] + offset.
Notice that is not relative to optimizations at all at this moment.

H.J. Lu writes: "I am proposing to add a new relocation, R_386_GOT32X, to i386 psABI. 
Instead of generating R_386_GOT32 relocation agasint foo for 
foo at GOT(%reg), we generate R_386_GOT32X.  **R_386_GOT32X relocation can 
also be used without the base register for the global offset table, 
foo at GOT, when position-independent code is disable.  In this case, the 
static base address of the global offset table will be used instead. **
Linker can treat R_386_GOT32X the same as R_386_GOT32 or it can perform 
the transformations listed above. "

Here is a patch by H.J. Lu for gold:
https://sourceware.org/ml/binutils/2015-10/msg00259.html
(See that place below, notice it touches both relaxed and not relaxed cases)
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gold/i386.cc;h=0b447ef0d68f3ea8965091502d5a1302d69d1b32;hb=HEAD#l2916)

At fact both gold and bfd implement R_386_GOT32 and R_386_GOT32X in the same way:

- G + A - GOT for case when base register present
- G + A when base register is absent (only allowed for no-PIC).

(that is how R_386_GOT32X must be evaluated according to ABI, see p36).

My patch changes calculation for R_386_GOT32X only for now, because 2 different calculations
are mentioned on p36 of ABI (https://github.com/hjl-tools/x86-psABI/wiki/intel386-psABI-1.1.pdf) for this
relocation and not for R_386_GOT32. Though we might want to follow GNU linkers behavior probably and do that for
R_386_GOT32 too (I would do that separatelly).


https://reviews.llvm.org/D30699