forked from OSchip/llvm-project
Inline a trivial function and update comment. NFC.
llvm-svn: 353200
This commit is contained in:
parent
76f787424d
commit
3fdb07258b
|
@ -66,8 +66,6 @@ X86::X86() {
|
||||||
DefaultImageBase = 0x400000;
|
DefaultImageBase = 0x400000;
|
||||||
}
|
}
|
||||||
|
|
||||||
static bool hasBaseReg(uint8_t ModRM) { return (ModRM & 0xc7) != 0x5; }
|
|
||||||
|
|
||||||
RelExpr X86::getRelExpr(RelType Type, const Symbol &S,
|
RelExpr X86::getRelExpr(RelType Type, const Symbol &S,
|
||||||
const uint8_t *Loc) const {
|
const uint8_t *Loc) const {
|
||||||
switch (Type) {
|
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.
|
// 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
|
// 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
|
// 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
|
// 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
|
// 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'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
|
// 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.
|
// 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
|
// different use cases. In order to distinguish them, we have to read a
|
||||||
// machine instruction.
|
// machine instruction.
|
||||||
//
|
//
|
||||||
// The following code implements it. We assume that Loc[0] is the first
|
// The following code implements it. We assume that Loc[0] is the first byte
|
||||||
// byte of a displacement or an immediate field of a valid machine
|
// 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
|
// 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
|
// the byte, we can determine whether the instruction uses the operand as an
|
||||||
// (i.e. it was generated for foo@GOT(%reg)) or absolute (i.e. foo@GOT).
|
// absolute address (R_GOT) or a register-relative address (R_GOT_FROM_END).
|
||||||
return hasBaseReg(Loc[-1]) ? R_GOT_FROM_END : R_GOT;
|
return (Loc[-1] & 0xc7) == 0x5 ? R_GOT : R_GOT_FROM_END;
|
||||||
case R_386_TLS_GOTIE:
|
case R_386_TLS_GOTIE:
|
||||||
return R_GOT_FROM_END;
|
return R_GOT_FROM_END;
|
||||||
case R_386_GOTOFF:
|
case R_386_GOTOFF:
|
||||||
|
|
Loading…
Reference in New Issue