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) {
// 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.
//
// 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: