From 3fdb07258b941eb4f52d5a964f2a67f87d906222 Mon Sep 17 00:00:00 2001 From: Rui Ueyama Date: Tue, 5 Feb 2019 19:19:45 +0000 Subject: [PATCH] Inline a trivial function and update comment. NFC. llvm-svn: 353200 --- lld/ELF/Arch/X86.cpp | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/lld/ELF/Arch/X86.cpp b/lld/ELF/Arch/X86.cpp index 76e56ea..0af3c4d 100644 --- a/lld/ELF/Arch/X86.cpp +++ b/lld/ELF/Arch/X86.cpp @@ -66,8 +66,6 @@ X86::X86() { DefaultImageBase = 0x400000; } -static bool hasBaseReg(uint8_t ModRM) { return (ModRM & 0xc7) != 0x5; } - RelExpr X86::getRelExpr(RelType Type, const Symbol &S, const uint8_t *Loc) const { switch (Type) { @@ -107,14 +105,14 @@ RelExpr X86::getRelExpr(RelType Type, const Symbol &S, // load an GOT address to a register, which is usually %ebx. // // So, there are two ways to refer to symbol foo's GOT entry: foo@GOT or - // foo@GOT(%reg). + // foo@GOT(%ebx). // // foo@GOT is not usable in PIC. If we are creating a PIC output and if we // find such relocation, we should report an error. foo@GOT is resolved to // an *absolute* address of foo's GOT entry, because both GOT address and // foo's offset are known. In other words, it's G + A. // - // foo@GOT(%reg) needs to be resolved to a *relative* offset from a GOT to + // foo@GOT(%ebx) needs to be resolved to a *relative* offset from a GOT to // foo's GOT entry in the table, because GOT address is not known but foo's // offset in the table is known. It's G + A - GOT. // @@ -122,12 +120,12 @@ RelExpr X86::getRelExpr(RelType Type, const Symbol &S, // different use cases. In order to distinguish them, we have to read a // machine instruction. // - // The following code implements it. We assume that Loc[0] is the first - // byte of a displacement or an immediate field of a valid machine + // The following code implements it. We assume that Loc[0] is the first byte + // of a displacement or an immediate field of a valid machine // instruction. That means a ModRM byte is at Loc[-1]. By taking a look at - // the byte, we can determine whether the instruction is register-relative - // (i.e. it was generated for foo@GOT(%reg)) or absolute (i.e. foo@GOT). - return hasBaseReg(Loc[-1]) ? R_GOT_FROM_END : R_GOT; + // the byte, we can determine whether the instruction uses the operand as an + // absolute address (R_GOT) or a register-relative address (R_GOT_FROM_END). + return (Loc[-1] & 0xc7) == 0x5 ? R_GOT : R_GOT_FROM_END; case R_386_TLS_GOTIE: return R_GOT_FROM_END; case R_386_GOTOFF: -- 2.7.4