Fix up MCFixup::getAccessVariant to handle unary expressions.

This allows correct relocations to be generated for a symbolic
address that is being adjusted by a negative constant. Since r204294,
such expressions have triggered undefined behavior when LLVM was built
without assertions.

Credit goes to Rafael for this patch; I'm submitting it on his behalf
as he is on vacation this week.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206192 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Kaelyn Takata 2014-04-14 16:50:22 +00:00
parent adc90c9d6d
commit de2b2a32f4
2 changed files with 9 additions and 1 deletions

View File

@ -12,7 +12,12 @@ using namespace llvm;
static MCSymbolRefExpr::VariantKind getAccessVariant(const MCExpr *Expr) {
switch (Expr->getKind()) {
case MCExpr::Unary:
case MCExpr::Unary: {
const MCUnaryExpr *UE = cast<MCUnaryExpr>(Expr);
assert(getAccessVariant(UE->getSubExpr()) == MCSymbolRefExpr::VK_None);
return MCSymbolRefExpr::VK_None;
}
case MCExpr::Target:
llvm_unreachable("unsupported");

View File

@ -28,6 +28,8 @@ bar:
zed = foo +2
call zed@PLT
leaq -1+foo(%rip), %r11
// CHECK: Section {
// CHECK: Name: .rela.text
// CHECK: Relocations [
@ -53,6 +55,7 @@ bar:
// CHECK-NEXT: 0x8D R_X86_64_PC16 foo 0x8D
// CHECK-NEXT: 0x8F R_X86_64_PC8 foo 0x8F
// CHECK-NEXT: 0x91 R_X86_64_PLT32 foo 0xFFFFFFFFFFFFFFFE
// CHECK-NEXT: 0x98 R_X86_64_PC32 foo 0xFFFFFFFFFFFFFFFB
// CHECK-NEXT: ]
// CHECK-NEXT: }