[llvm-commits] [rfc][patch] How should we handle _GLOBAL_OFFSET_TABLE_?

[Rafael Espíndola]

>> The "2" in the add comes from the first two bytes. This is a special
>> treatment for _GLOBAL_OFFSET_TABLE_. It also produces a special kind
>> of relocation (R_386_GOTPC).
>
> Is it too late to do it when the special relocation is generated? Or
> does that happen inside the ELF streamer/writer?

Yes and yes. It is done by just checking the symbol name. At that
point the instruction will already be concatenated with previous
instructions and I cannot compute the offset from the start of it.

>> The relocation kind can be handled in the writer (and is). The problem
>> is that it is then too late to find the offset of the relocation
>> inside the instruction. This patch does it by modifying
>> X86MCCodeEmitter.cpp. This might be undesirable as this code is also
>> used for non-ELF targets.
>
> I tend to dislike relying on string literals, but this patch seems to
> be fine for now. The relocation is x86 specific, so I would think that
> it is OK for this to occur in the x86 back-end.

I *really* dislike the use of a magical symbol name, unfortunately
that is what the ELF x86 ABI does :-( My hope was to put this is a
ELF/x86 only place. Right now it also affects COFF and MachO.

>> Any better ideas on how to implement this?
>
> I would prefer this happen whenever the relocation is generated in the
> x86 backend. Object file formats really shouldn't care about
> instructions. I don't object to adding an object specific hook, but it
> does seem to be of limited use.

It is. It was just my desire to keep this out of non-ELF systems.

>> P.S.: Ugly as the attached patch is, it gets clang to build itself on
>> 32 bits with the integrated assembler :-)
>>
>> Cheers,
>> Rafael
>
> This patch (with some comments) looks fine to me for now, but I would
> prefer a solution that doesn't depend on the symbol name.

Thanks. I will add comments and commit. One possible future
improvement is to produce a new FixupKind so that the string compare
happens in only one place.

> - Michael Spencer
>

Cheers,
Rafael