Date: Thu, 16 Jan 2020 14:14:50 +0000 (UTC) From: Alex Richardson <arichardson@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r356789 - in head/contrib/llvm-project/llvm/lib: MC Object Target/Mips Message-ID: <202001161414.00GEEoeh078526@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
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)); } }
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202001161414.00GEEoeh078526>