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

Michael Spencer bigcheesegs at gmail.com
Tue Oct 19 16:20:51 PDT 2010


2010/10/19 Rafael Espíndola <rafael.espindola at gmail.com>:
> Consider the instruction
>
> addl    $_GLOBAL_OFFSET_TABLE_, %ebx
>
> It should assemble to something like
>
> 81 c3 02 00 00 00       add    $0x2,%ebx
>
> 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?

> 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 tried to do this on the ELF streamer, but failed because
> EncodeInstruction is also called directly from the assembler when
> handling relaxations and the streamer cannot patch it up.
>
> Another way I can see this being done is having a object specific
> wrapper for CodeEmitter::EncodeInstruction. This would be a nop for
> MachO and COFF, but ELF 32 bits could then patch it up to account for
> _GLOBAL_OFFSET_TABLE_.
>
> 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.

> 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.

- Michael Spencer




More information about the llvm-commits mailing list