X86MCCodeEmitter: Fix two minor issues with reloc_riprel_4byte_movq_load, we

were missing it on some movq instructions and were not including the appropriate
PCrel bias.

llvm-svn: 98880
This commit is contained in:
Daniel Dunbar 2010-03-18 21:53:54 +00:00
parent 2130a3e0af
commit 2ca1108254
2 changed files with 10 additions and 3 deletions

View File

@ -166,7 +166,8 @@ EmitImmediate(const MCOperand &DispOp, unsigned Size, MCFixupKind FixupKind,
// If the fixup is pc-relative, we need to bias the value to be relative to
// the start of the field, not the end of the field.
if (FixupKind == MCFixupKind(X86::reloc_pcrel_4byte) ||
FixupKind == MCFixupKind(X86::reloc_riprel_4byte))
FixupKind == MCFixupKind(X86::reloc_riprel_4byte) ||
FixupKind == MCFixupKind(X86::reloc_riprel_4byte_movq_load))
ImmOffset -= 4;
if (FixupKind == MCFixupKind(X86::reloc_pcrel_1byte))
ImmOffset -= 1;
@ -203,7 +204,8 @@ void X86MCCodeEmitter::EmitMemModRMByte(const MCInst &MI, unsigned Op,
// movq loads are handled with a special relocation form which allows the
// linker to eliminate some loads for GOT references which end up in the
// same linkage unit.
if (MI.getOpcode() == X86::MOV64rm_TC)
if (MI.getOpcode() == X86::MOV64rm ||
MI.getOpcode() == X86::MOV64rm_TC)
FixupKind = X86::reloc_riprel_4byte_movq_load;
// rip-relative addressing is actually relative to the *next* instruction.

View File

@ -32,9 +32,14 @@ addq $-424, %rax
// CHECK: movq _foo@GOTPCREL(%rip), %rax
// CHECK: encoding: [0x48,0x8b,0x05,A,A,A,A]
// CHECK: fixup A - offset: 3, value: _foo@GOTPCREL, kind: reloc_riprel_4byte_movq_load
// CHECK: fixup A - offset: 3, value: _foo@GOTPCREL-4, kind: reloc_riprel_4byte_movq_load
movq _foo@GOTPCREL(%rip), %rax
// CHECK: movq _foo@GOTPCREL(%rip), %r14
// CHECK: encoding: [0x4c,0x8b,0x35,A,A,A,A]
// CHECK: fixup A - offset: 3, value: _foo@GOTPCREL-4, kind: reloc_riprel_4byte_movq_load
movq _foo@GOTPCREL(%rip), %r14
// CHECK: movq (%r13,%rax,8), %r13
// CHECK: encoding: [0x4d,0x8b,0x6c,0xc5,0x00]