From owner-svn-src-stable@freebsd.org Mon Jan 27 07:02:53 2020 Return-Path: Delivered-To: svn-src-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4C040234372; Mon, 27 Jan 2020 07:02:53 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 485ggK1C3Wz42bv; Mon, 27 Jan 2020 07:02:53 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 2490F6452; Mon, 27 Jan 2020 07:02:53 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id 00R72rDO003728; Mon, 27 Jan 2020 07:02:53 GMT (envelope-from dim@FreeBSD.org) Received: (from dim@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id 00R72qbe003726; Mon, 27 Jan 2020 07:02:52 GMT (envelope-from dim@FreeBSD.org) Message-Id: <202001270702.00R72qbe003726@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: dim set sender to dim@FreeBSD.org using -f From: Dimitry Andric Date: Mon, 27 Jan 2020 07:02:52 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-12@freebsd.org Subject: svn commit: r357167 - in stable/12/contrib/llvm-project/llvm/lib: MC Object Target/Mips X-SVN-Group: stable-12 X-SVN-Commit-Author: dim X-SVN-Commit-Paths: in stable/12/contrib/llvm-project/llvm/lib: MC Object Target/Mips X-SVN-Commit-Revision: 357167 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 07:02:53 -0000 Author: dim Date: Mon Jan 27 07:02:52 2020 New Revision: 357167 URL: https://svnweb.freebsd.org/changeset/base/357167 Log: MFC r356789 (by arichardson): 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 Differential Revision: https://reviews.freebsd.org/D23203 Modified: stable/12/contrib/llvm-project/llvm/lib/MC/MCObjectFileInfo.cpp stable/12/contrib/llvm-project/llvm/lib/Object/RelocationResolver.cpp stable/12/contrib/llvm-project/llvm/lib/Target/Mips/MipsISelLowering.cpp Directory Properties: stable/12/ (props changed) stable/12/contrib/llvm-project/llvm/ (props changed) Modified: stable/12/contrib/llvm-project/llvm/lib/MC/MCObjectFileInfo.cpp ============================================================================== --- stable/12/contrib/llvm-project/llvm/lib/MC/MCObjectFileInfo.cpp Mon Jan 27 06:05:43 2020 (r357166) +++ stable/12/contrib/llvm-project/llvm/lib/MC/MCObjectFileInfo.cpp Mon Jan 27 07:02:52 2020 (r357167) @@ -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: stable/12/contrib/llvm-project/llvm/lib/Object/RelocationResolver.cpp ============================================================================== --- stable/12/contrib/llvm-project/llvm/lib/Object/RelocationResolver.cpp Mon Jan 27 06:05:43 2020 (r357166) +++ stable/12/contrib/llvm-project/llvm/lib/Object/RelocationResolver.cpp Mon Jan 27 07:02:52 2020 (r357167) @@ -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: stable/12/contrib/llvm-project/llvm/lib/Target/Mips/MipsISelLowering.cpp ============================================================================== --- stable/12/contrib/llvm-project/llvm/lib/Target/Mips/MipsISelLowering.cpp Mon Jan 27 06:05:43 2020 (r357166) +++ stable/12/contrib/llvm-project/llvm/lib/Target/Mips/MipsISelLowering.cpp Mon Jan 27 07:02:52 2020 (r357167) @@ -2995,6 +2995,14 @@ void MipsTargetLowering::AdjustInstrPostInstrSelection StringRef Sym; if (const GlobalAddressSDNode *G = dyn_cast_or_null(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(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)); } }