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

[Rafael Espíndola]

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

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

P.S.: Ugly as the attached patch is, it gets clang to build itself on
32 bits with the integrated assembler :-)

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GlobalOffsetTable.patch
Type: text/x-patch
Size: 1664 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20101019/ff90b747/attachment.bin>