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

[Michael Spencer]

2010/10/20 Rafael Espíndola <rafael.espindola at gmail.com>:
>>> 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.

I like that idea.

- Michael Spencer

>> - Michael Spencer
>>
>
> Cheers,
> Rafael
>