[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#703365, @ruiu wrote:

> My apologies, but I'm really confused by your conflicting responses about this patch.
>
> H.J. Lu said that GOT and GOTX are handled as the same relocation if linkers decide to not optimize them. You agreed with that.


I agreed "in short", sorry probably "in short" format was not good format here to explain.

See what he is exactly saying: "**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. "

See ? Latter bold part partially conflicts with first part. 
He does not say that R_386_GOT32 can be "used without base register ....", he said that only for R_386_GOT32X.
And current ABI does not say that. So in short R_386_GOT32X != R_386_GOT32 even for non-optimized case.

> Therefore, I suggested handling them as the same relocation, because that's at least not wrong.

It can't be wrong, otherwize GNU linkers would generate broken output (I did not notice complains about that, so I assume 
they don't do that, that works for years), but it seems useless to handle them as the same relocation now (2017 year). 
And it is definetely would be a change incompatible with ABI.

> And then you are saying that that is wrong. Your explanation is too detailed, and I don't get the gist of that. Simply put, is H.J. Lu.'s comment wrong?

If I should answer basing just on what ABI currently says, then statement "can treat R_386_GOT32X the same as R_386_GOT32" is not correct,
but it just should not be read outside of whole message context.

For baseless code like "movl	bar at GOT, %eax", GNU as v.2.27 generates R_386_GOT32X and not R_386_GOT32. 
So current behavior of GNU as matches the ABI, though both gold and bfd also handle R_386_GOT32 for case "without the base register". 
I assume that was implemented to support some outdated producers (I don't know exactly, but that would explain everything),
but that is incompatible with what ABI explicitly says.

I do not see reasons to just blindly copy behavior of gold/bfd and handle R_386_GOT32 in the same way right now.


https://reviews.llvm.org/D30699