svn commit: r356789 - in head/contrib/llvm-project/llvm/lib: MC Object Target/Mips
Alex Richardson
arichardson at FreeBSD.org
Thu Jan 16 14:14:51 UTC 2020
Author: arichardson
Date: Thu Jan 16 14:14:50 2020
New Revision: 356789
URL: https://svnweb.freebsd.org/changeset/base/356789
Log:
Merge commit 894f742acb from llvm git (by me):
[MIPS][ELF] Use PC-relative relocations in .eh_frame when possible
When compiling position-independent executables, we now use
DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a
64-bit PC-relative ELF relocation so we cannot use sdata8 for the large
code model case. When using the large code model, we fall back to the
previous behaviour of generating absolute relocations.
With this change clang-generated .o files can be linked by LLD without
having to pass -Wl,-z,notext (which creates text relocations).
This is simpler than the approach used by ld.bfd, which rewrites the
.eh_frame section to convert absolute relocations into relative references.
I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations
for MIPS ouput at some point. However, I also checked that recent ld.bfd
can process the clang-generated .o files so this no longer seems true.
Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D72228
Merge commit 8e8ccf47 from llvm git (by me)
[MIPS] Don't emit R_(MICRO)MIPS_JALR relocations against data symbols
The R_(MICRO)MIPS_JALR optimization only works when used against functions.
Using the relocation against a data symbol (e.g. function pointer) will
cause some linkers that don't ignore the hint in this case (e.g. LLD prior
to commit 5bab291) to generate a relative branch to the data symbol
which crashes at run time. Before this patch, LLVM was erroneously emitting
these relocations against local-dynamic TLS function pointers and global
function pointers with internal visibility.
Reviewers: atanasyan, jrtc27, vstefanovic
Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D72571
These two changes should allow using lld for MIPS64 (and maybe also MIPS32)
by default.
The second commit is not strictly necessary for clang+lld since LLD9 will
not perform the R_MIPS_JALR optimization (it was only added for 10) but it
is probably required in order to use recent ld.bfd.
Reviewed By: dim, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D23203
Modified:
head/contrib/llvm-project/llvm/lib/MC/MCObjectFileInfo.cpp
head/contrib/llvm-project/llvm/lib/Object/RelocationResolver.cpp
head/contrib/llvm-project/llvm/lib/Target/Mips/MipsISelLowering.cpp
Modified: head/contrib/llvm-project/llvm/lib/MC/MCObjectFileInfo.cpp
==============================================================================
--- head/contrib/llvm-project/llvm/lib/MC/MCObjectFileInfo.cpp Thu Jan 16 11:33:15 2020 (r356788)
+++ head/contrib/llvm-project/llvm/lib/MC/MCObjectFileInfo.cpp Thu Jan 16 14:14:50 2020 (r356789)
@@ -303,9 +303,14 @@ void MCObjectFileInfo::initELFMCObjectFileInfo(const T
case Triple::mipsel:
case Triple::mips64:
case Triple::mips64el:
- FDECFIEncoding = Ctx->getAsmInfo()->getCodePointerSize() == 4
- ? dwarf::DW_EH_PE_sdata4
- : dwarf::DW_EH_PE_sdata8;
+ // We cannot use DW_EH_PE_sdata8 for the large PositionIndependent case
+ // since there is no R_MIPS_PC64 relocation (only a 32-bit version).
+ if (PositionIndependent && !Large)
+ FDECFIEncoding = dwarf::DW_EH_PE_pcrel | dwarf::DW_EH_PE_sdata4;
+ else
+ FDECFIEncoding = Ctx->getAsmInfo()->getCodePointerSize() == 4
+ ? dwarf::DW_EH_PE_sdata4
+ : dwarf::DW_EH_PE_sdata8;
break;
case Triple::ppc64:
case Triple::ppc64le:
Modified: head/contrib/llvm-project/llvm/lib/Object/RelocationResolver.cpp
==============================================================================
--- head/contrib/llvm-project/llvm/lib/Object/RelocationResolver.cpp Thu Jan 16 11:33:15 2020 (r356788)
+++ head/contrib/llvm-project/llvm/lib/Object/RelocationResolver.cpp Thu Jan 16 14:14:50 2020 (r356789)
@@ -103,6 +103,7 @@ static bool supportsMips64(uint64_t Type) {
case ELF::R_MIPS_32:
case ELF::R_MIPS_64:
case ELF::R_MIPS_TLS_DTPREL64:
+ case ELF::R_MIPS_PC32:
return true;
default:
return false;
@@ -117,6 +118,8 @@ static uint64_t resolveMips64(RelocationRef R, uint64_
return S + getELFAddend(R);
case ELF::R_MIPS_TLS_DTPREL64:
return S + getELFAddend(R) - 0x8000;
+ case ELF::R_MIPS_PC32:
+ return S + getELFAddend(R) - R.getOffset();
default:
llvm_unreachable("Invalid relocation type");
}
Modified: head/contrib/llvm-project/llvm/lib/Target/Mips/MipsISelLowering.cpp
==============================================================================
--- head/contrib/llvm-project/llvm/lib/Target/Mips/MipsISelLowering.cpp Thu Jan 16 11:33:15 2020 (r356788)
+++ head/contrib/llvm-project/llvm/lib/Target/Mips/MipsISelLowering.cpp Thu Jan 16 14:14:50 2020 (r356789)
@@ -2995,6 +2995,14 @@ void MipsTargetLowering::AdjustInstrPostInstrSelection
StringRef Sym;
if (const GlobalAddressSDNode *G =
dyn_cast_or_null<const GlobalAddressSDNode>(TargetAddr)) {
+ // We must not emit the R_MIPS_JALR relocation against data symbols
+ // since this will cause run-time crashes if the linker replaces the
+ // call instruction with a relative branch to the data symbol.
+ if (!isa<Function>(G->getGlobal())) {
+ LLVM_DEBUG(dbgs() << "Not adding R_MIPS_JALR against data symbol "
+ << G->getGlobal()->getName() << "\n");
+ return;
+ }
Sym = G->getGlobal()->getName();
}
else if (const ExternalSymbolSDNode *ES =
@@ -3007,6 +3015,7 @@ void MipsTargetLowering::AdjustInstrPostInstrSelection
MachineFunction *MF = MI.getParent()->getParent();
MCSymbol *S = MF->getContext().getOrCreateSymbol(Sym);
+ LLVM_DEBUG(dbgs() << "Adding R_MIPS_JALR against " << Sym << "\n");
MI.addOperand(MachineOperand::CreateMCSymbol(S, MipsII::MO_JALR));
}
}
More information about the svn-src-all
mailing list