Alessandro Pistocchi via llvm-dev
2017-Jun-27 10:47 UTC
[llvm-dev] Building llvm with clang and lld on arm and the llvm arm backend relocation on position independent code
> On 26 Jun 2017, at 16:25, Rui Ueyama <ruiu at google.com> wrote: > > On Sun, Jun 25, 2017 at 6:40 AM, Alessandro Pistocchi via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hi, > > I am trying to build a completely GNU free linux toolchain for the raspberry pi. > > I successfully managed to compile llvm and clang for armv7 hard float ( both as a cross compiler and as a native compiler ) together with the following: > > Llvm with clang and lld > Clang builtins > Musl libc > libc++, libc++abi, libunwind > > All works well with the only thing to notice being the need to use -fPIC in order to access some library functions when my own c/c++ programs access those functions. > > The fact seems to be that musl libc exports some symbols as protected ( probably correctly ) and lld ( probably correctly ) says it cannot preempt those symbols. > For this reason I seem to have to use -fPIC in the C and CXX flags but everything seems to work ok. > > Is this the same problem mentioned in https://bugs.llvm.org/show_bug.cgi?id=32425? <https://bugs.llvm.org/show_bug.cgi?id=32425?>My aim is to build llvm+clang+lld using llvm+clang+lld on arm ( using musl, libc++, libc++abi, libunwind and the clang builtins, no gcc runtime at all ). I think the fact that lld cannot preempt some symbols without using -fPIC is similar to the problem mentioned in https://bugs.llvm.org/show_bug.cgi?id=32425 <https://bugs.llvm.org/show_bug.cgi?id=32425> . However I am not particularly bothered at this stage about having to use -fPIC. That would be fine. What I am struggling with is that having to use -fPIC is in conflict with the arm backend issue that creates bad relocations when building clang with -fPIC as mentioned in http://llvm.org/docs/HowToCrossCompileLLVM.html <http://llvm.org/docs/HowToCrossCompileLLVM.html> and so the build with -fPIC fails when building the clang binary. Regarding https://bugs.llvm.org/show_bug.cgi?id=32425 <https://bugs.llvm.org/show_bug.cgi?id=32425> , please notice that contrary to what is reported there I definitely can build and execute a C hello world program without having to use -fPIC. It is only some symbols from musl that cannot be preempted by lld, not all of them. Unfortunately, when building llvm+clang+lld quite a few of those symbols are explicitly looked for by cmake and not found unless I use -fPIC. If I go ahead and build without using -fPIC then the build fails because it cannot preempt those symbols. It looks like a paradox to me and I think the solution would be to fix the fact that the arm backend does not like -fPIC as mentioned in http://llvm.org/docs/HowToCrossCompileLLVM.html <http://llvm.org/docs/HowToCrossCompileLLVM.html> . While it is probably correct that lld says it cannot preempt protected symbols, the arm backend issue is a known issue.> > Then I tried to use this compiler ( both the cross compiler and the native compiler ) to compile llvm + clang + lld ( I want to have the toolchain built with itself, again without any GNU software involved ) but when building the clang executable I ran into the arm relocation problems mentioned here in the “Hacks” section when using -fPIC: http://llvm.org/docs/HowToCrossCompileLLVM.html <http://llvm.org/docs/HowToCrossCompileLLVM.html> . > On the other hand, I seem to need -fPIC otherwise cmake fails to find some libc functions such as futimes/futimens and many others. If I use -fPIC for CFLAGS but not for CXXFLAGS then cmake finds those symbols but then obviously fails at a later stage with lld unable to preempt those symbols. > > This seems to be a conflict I cannot solve without someone within the llvm team fixing the arm relocation problem. Is there any estimate of when this could happen? I am happy to spend the time testing any solutions by building my own toolchain until it succeeds. Or is there any other solution? > > Thank you, > Alex > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170627/7063f9f4/attachment.html>
Peter Smith via llvm-dev
2017-Jun-27 12:25 UTC
[llvm-dev] Building llvm with clang and lld on arm and the llvm arm backend relocation on position independent code
Hello Alessandro, Despite the statement in the HowToCrossCompileLLVM guide "If you’re using Clang as the cross-compiler, there is a problem in the LLVM ARM back-end that is producing absolute relocations on position-independent code (R_ARM_THM_MOVW_ABS_NC), so for now, you should disable PIC:" I can't find an existing upstream PR or any record that this has been fixed. If the ARM backend is still producing an R_ARM_THM_MOVW_ABS_NC relocation when -fpic is given as an option then it would be great to get a small reproducible example in a new PR, or if there is one already to update it. The last time I ran into this error when trying to cross compile was that a dependency not compiled by clang (libtinfo.a) library contained an R_ARM_THM_MOVW_ABS_NC relocation. I don't think that this is the fault of clang/llvm though, I think it was my fault in installing a non pic compiled version of libtinfo.a (I'm still trying to learn how Ubuntu multilibs work). Would it be possible for you to share the details of which objects contain the R_ARM_THM_MOVW_ABS_NC relocations when compiled -fpic? Peter On 27 June 2017 at 11:47, Alessandro Pistocchi via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > On 26 Jun 2017, at 16:25, Rui Ueyama <ruiu at google.com> wrote: > > On Sun, Jun 25, 2017 at 6:40 AM, Alessandro Pistocchi via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> I am trying to build a completely GNU free linux toolchain for the >> raspberry pi. >> >> I successfully managed to compile llvm and clang for armv7 hard float ( >> both as a cross compiler and as a native compiler ) together with the >> following: >> >> Llvm with clang and lld >> Clang builtins >> Musl libc >> libc++, libc++abi, libunwind >> >> All works well with the only thing to notice being the need to use -fPIC >> in order to access some library functions when my own c/c++ programs access >> those functions. >> >> The fact seems to be that musl libc exports some symbols as protected ( >> probably correctly ) and lld ( probably correctly ) says it cannot preempt >> those symbols. >> For this reason I seem to have to use -fPIC in the C and CXX flags but >> everything seems to work ok. > > > Is this the same problem mentioned in > https://bugs.llvm.org/show_bug.cgi?id=32425? > > > My aim is to build llvm+clang+lld using llvm+clang+lld on arm ( using musl, > libc++, libc++abi, libunwind and the clang builtins, no gcc runtime at all > ). > > I think the fact that lld cannot preempt some symbols without using -fPIC is > similar to the problem mentioned in > https://bugs.llvm.org/show_bug.cgi?id=32425 . > > However I am not particularly bothered at this stage about having to use > -fPIC. That would be fine. > > What I am struggling with is that having to use -fPIC is in conflict with > the arm backend issue that creates bad relocations when building clang with > -fPIC as mentioned in http://llvm.org/docs/HowToCrossCompileLLVM.html and so > the build with -fPIC fails when building the clang binary. > > Regarding https://bugs.llvm.org/show_bug.cgi?id=32425 , please notice that > contrary to what is reported there I definitely can build and execute a C > hello world program without having to use -fPIC. > > It is only some symbols from musl that cannot be preempted by lld, not all > of them. > > Unfortunately, when building llvm+clang+lld quite a few of those symbols are > explicitly looked for by cmake and not found unless I use -fPIC. > > If I go ahead and build without using -fPIC then the build fails because it > cannot preempt those symbols. > > It looks like a paradox to me and I think the solution would be to fix the > fact that the arm backend does not like -fPIC as mentioned in > http://llvm.org/docs/HowToCrossCompileLLVM.html . While it is probably > correct that lld says it cannot preempt protected symbols, the arm backend > issue is a known issue. > > >> >> Then I tried to use this compiler ( both the cross compiler and the native >> compiler ) to compile llvm + clang + lld ( I want to have the toolchain >> built with itself, again without any GNU software involved ) but when >> building the clang executable I ran into the arm relocation problems >> mentioned here in the “Hacks” section when using -fPIC: >> http://llvm.org/docs/HowToCrossCompileLLVM.html . >> On the other hand, I seem to need -fPIC otherwise cmake fails to find some >> libc functions such as futimes/futimens and many others. If I use -fPIC for >> CFLAGS but not for CXXFLAGS then cmake finds those symbols but then >> obviously fails at a later stage with lld unable to preempt those symbols. >> >> This seems to be a conflict I cannot solve without someone within the llvm >> team fixing the arm relocation problem. Is there any estimate of when this >> could happen? I am happy to spend the time testing any solutions by building >> my own toolchain until it succeeds. Or is there any other solution? >> >> Thank you, >> Alex >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >
Alessandro Pistocchi via llvm-dev
2017-Jun-28 16:09 UTC
[llvm-dev] Building llvm with clang and lld on arm and the llvm arm backend relocation on position independent code
> On 27 Jun 2017, at 13:25, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Alessandro, > > Despite the statement in the HowToCrossCompileLLVM guide "If you’re > using Clang as the cross-compiler, there is a problem in the LLVM ARM > back-end that is producing absolute relocations on > position-independent code (R_ARM_THM_MOVW_ABS_NC), so for now, you > should disable PIC:" I can't find an existing upstream PR or any > record that this has been fixed. If the ARM backend is still producing > an R_ARM_THM_MOVW_ABS_NC relocation when -fpic is given as an option > then it would be great to get a small reproducible example in a new > PR, or if there is one already to update it. > > The last time I ran into this error when trying to cross compile was > that a dependency not compiled by clang (libtinfo.a) library contained > an R_ARM_THM_MOVW_ABS_NC relocation. I don't think that this is the > fault of clang/llvm though, I think it was my fault in installing a > non pic compiled version of libtinfo.a (I'm still trying to learn how > Ubuntu multilibs work). > > Would it be possible for you to share the details of which objects > contain the R_ARM_THM_MOVW_ABS_NC relocations when compiled -fpic?Hi, the errors I get do not seen to mention R_ARM_THM_MOVW_ABS_NC. The errors are “relocation R_ARM_CALL out of range”. Today I recompiled everything from scratch with -fPIC to make sure I had no library compiled without it and I still get the same errors. Sorry, I could not find any trivial code that has the same issue yet. Following is the output of the compilation process: yawmoo at yawmoo-MRNM3AP:~/Desktop/clfs/sources/llvm-build-native-with-lld$ cmake --build . [ 0%] Built target LLVMDemangle [ 3%] Built target LLVMSupport [ 3%] Built target LLVMTableGen [ 4%] Built target obj.llvm-tblgen [ 4%] Built target llvm-tblgen [ 4%] Built target AttributeCompatFuncTableGen [ 4%] Built target intrinsics_gen [ 6%] Built target LLVMCore [ 6%] Built target LLVMIRReader [ 13%] Built target LLVMCodeGen [ 14%] Built target LLVMSelectionDAG [ 14%] Built target LLVMAsmPrinter [ 14%] Built target LLVMMIRParser [ 14%] Built target LLVMGlobalISel [ 14%] Built target LLVMBinaryFormat [ 14%] Built target LLVMBitReader [ 16%] Built target LLVMBitWriter [ 18%] Built target LLVMTransformUtils [ 19%] Built target LLVMInstrumentation [ 19%] Built target LLVMInstCombine [ 22%] Built target LLVMScalarOpts [ 22%] Built target LLVMipo [ 24%] Built target LLVMVectorize [ 24%] Built target LLVMHello_exports [ 24%] Built target LLVMHello [ 26%] Built target LLVMObjCARCOpts [ 26%] Built target LLVMCoroutines [ 26%] Built target LLVMLinker [ 29%] Built target LLVMAnalysis [ 29%] Built target llvm_vcsrevision_h [ 29%] Built target LLVMLTO [ 32%] Built target LLVMMC [ 32%] Built target LLVMMCParser [ 32%] Built target LLVMMCDisassembler [ 32%] Built target LLVMObject [ 32%] Built target LLVMObjectYAML [ 34%] Built target LLVMOption [ 36%] Built target LLVMDebugInfoDWARF [ 36%] Built target LLVMDebugInfoMSF [ 37%] Built target LLVMDebugInfoCodeView [ 40%] Built target LLVMDebugInfoPDB [ 42%] Built target LLVMSymbolize [ 42%] Built target LLVMExecutionEngine [ 42%] Built target LLVMInterpreter [ 42%] Built target LLVMMCJIT [ 42%] Built target LLVMOrcJIT [ 42%] Built target LLVMRuntimeDyld [ 42%] Built target LLVMTarget [ 44%] Built target ARMCommonTableGen [ 45%] Built target LLVMARMCodeGen [ 45%] Built target LLVMARMInfo [ 45%] Built target LLVMARMAsmParser [ 45%] Built target LLVMARMDisassembler [ 45%] Built target LLVMARMAsmPrinter [ 45%] Built target LLVMARMDesc [ 47%] Built target LLVMAsmParser [ 47%] Built target LLVMLineEditor [ 47%] Built target LLVMProfileData [ 47%] Built target LLVMCoverage [ 49%] Built target LLVMFuzzerNoMainObjects [ 49%] Built target LLVMFuzzerNoMain [ 49%] Built target LLVMFuzzer [ 49%] Built target LLVMPasses [ 49%] Built target LibOptionsTableGen [ 49%] Built target LLVMLibDriver [ 49%] Built target LLVMXRay [ 49%] Built target gtest [ 49%] Built target LLVMTestingSupport [ 49%] Built target FileCheck [ 49%] Built target llvm-PerfectShuffle [ 49%] Built target count [ 49%] Built target not [ 49%] Built target yaml-bench [ 49%] Built target LTO_exports [ 50%] Built target LTO [ 50%] Built target llvm-ar [ 50%] Built target llvm-ranlib [ 50%] Built target llvm-lib [ 50%] Built target llvm-config [ 50%] Built target llvm-lto [ 50%] Built target llvm-profdata [ 50%] Built target obj.clang-tblgen [ 50%] Built target clang-tblgen [ 55%] Built target clang-headers [ 55%] Built target ClangSACheckers [ 55%] Built target ClangCommentCommandList [ 55%] Built target ClangCommentCommandInfo [ 55%] Built target ClangAttrVisitor [ 55%] Built target ClangCommentHTMLNamedCharacterReferences [ 55%] Built target ClangAttrDump [ 55%] Built target ClangAttrImpl [ 55%] Built target ClangAttrClasses [ 55%] Built target ClangStmtNodes [ 55%] Built target ClangDeclNodes [ 55%] Built target ClangCommentNodes [ 55%] Built target ClangCommentHTMLTagsProperties [ 55%] Built target ClangCommentHTMLTags [ 55%] Built target ClangDiagnosticIndexName [ 55%] Built target ClangDiagnosticSerialization [ 55%] Built target ClangDiagnosticAnalysis [ 55%] Built target ClangDiagnosticAST [ 55%] Built target ClangDiagnosticParse [ 55%] Built target ClangDiagnosticLex [ 55%] Built target ClangDiagnosticSema [ 55%] Built target ClangDiagnosticComment [ 57%] Built target ClangDiagnosticGroups [ 57%] Built target ClangDiagnosticDriver [ 57%] Built target ClangAttrList [ 57%] Built target ClangDiagnosticFrontend [ 57%] Built target ClangAttrHasAttributeImpl [ 57%] Built target ClangDiagnosticCommon [ 57%] Built target ClangAttrSubjectMatchRuleList [ 57%] Built target ClangARMNeon [ 59%] Built target ClangAttrParserStringSwitches [ 59%] Built target ClangAttrSubMatchRulesParserStringSwitches [ 59%] Built target ClangAttrParsedAttrKinds [ 59%] Built target ClangAttrSpellingListIndex [ 59%] Built target ClangAttrParsedAttrList [ 59%] Built target ClangAttrParsedAttrImpl [ 59%] Built target ClangAttrTemplateInstantiate [ 59%] Built target ClangAttrPCHRead [ 59%] Built target ClangAttrPCHWrite [ 60%] Built target clangBasic [ 62%] Built target clangLex [ 62%] Built target clangParse [ 63%] Built target clangAST [ 63%] Built target clangASTMatchers [ 63%] Built target clangDynamicASTMatchers [ 65%] Built target clangSema [ 67%] Built target clangCodeGen [ 68%] Built target clangAnalysis [ 68%] Built target clangEdit [ 70%] Built target clangRewrite [ 72%] Built target clangARCMigrate [ 72%] Built target ClangDriverOptions [ 75%] Built target clangDriver [ 75%] Built target clangSerialization [ 77%] Built target clangFrontend [ 77%] Built target clangRewriteFrontend [ 77%] Built target clangFrontendTool [ 77%] Built target clangTooling [ 77%] Built target clangToolingCore [ 77%] Built target clangToolingRefactor [ 77%] Built target clangIndex [ 78%] Built target clangStaticAnalyzerCore [ 83%] Built target clangStaticAnalyzerCheckers [ 83%] Built target clangStaticAnalyzerFrontend [ 83%] Built target clangFormat [ 85%] Built target diagtool [ 85%] Built target clang-offload-bundler [ 85%] Linking CXX executable ../../../../bin/clang /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/lib/Analysis/ObjCARCAliasAnalysis.cpp:(function llvm::Pass* llvm::callDefaultCtor<llvm::objcarc::ObjCARCAAWrapperPass>()): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/lib/Analysis/ObjCARCAliasAnalysis.cpp:(function llvm::Pass* llvm::callDefaultCtor<llvm::objcarc::ObjCARCAAWrapperPass>()): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/tools/clang/lib/StaticAnalyzer/Core/CallEvent.cpp:(function clang::ento::CXXDestructorCall* clang::ento::CallEventManager::create<clang::ento::CXXDestructorCall, clang::CXXDestructorDecl const*, clang::Stmt const*, clang::ento::MemRegion const*, bool>(clang::CXXDestructorDecl const*, clang::Stmt const*, clang::ento::MemRegion const*, bool, llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>, clang::LocationContext const*)): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/lib/Analysis/ObjCARCAliasAnalysis.cpp:(function llvm::Pass* llvm::callDefaultCtor<llvm::objcarc::ObjCARCAAWrapperPass>()): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/lib/Analysis/ObjCARCAliasAnalysis.cpp:(function llvm::Pass* llvm::callDefaultCtor<llvm::objcarc::ObjCARCAAWrapperPass>()): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/lib/Analysis/ObjCARCAliasAnalysis.cpp:(function llvm::Pass* llvm::callDefaultCtor<llvm::objcarc::ObjCARCAAWrapperPass>()): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/lib/Analysis/ObjCARCAnalysisUtils.cpp:(function llvm::cl::opt<bool, true, llvm::cl::parser<bool> >::opt<char [21], llvm::cl::desc, llvm::cl::LocationClass<bool>, llvm::cl::initializer<bool> >(char const (&) [21], llvm::cl::desc const&, llvm::cl::LocationClass<bool> const&, llvm::cl::initializer<bool> const&)): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/lib/Analysis/ObjCARCAnalysisUtils.cpp:(function llvm::cl::opt<bool, true, llvm::cl::parser<bool> >::opt<char [21], llvm::cl::desc, llvm::cl::LocationClass<bool>, llvm::cl::initializer<bool> >(char const (&) [21], llvm::cl::desc const&, llvm::cl::LocationClass<bool> const&, llvm::cl::initializer<bool> const&)): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/lib/Analysis/ObjCARCAnalysisUtils.cpp:(function llvm::cl::opt<bool, true, llvm::cl::parser<bool> >::opt<char [21], llvm::cl::desc, llvm::cl::LocationClass<bool>, llvm::cl::initializer<bool> >(char const (&) [21], llvm::cl::desc const&, llvm::cl::LocationClass<bool> const&, llvm::cl::initializer<bool> const&)): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/lib/Analysis/ObjCARCAnalysisUtils.cpp:(function _GLOBAL__sub_I_ObjCARCAnalysisUtils.cpp): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/lib/Analysis/ObjCARCInstKind.cpp:(function llvm::objcarc::operator<<(llvm::raw_ostream&, llvm::objcarc::ARCInstKind)): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/lib/Analysis/ObjCARCInstKind.cpp:(function llvm::objcarc::operator<<(llvm::raw_ostream&, llvm::objcarc::ARCInstKind)): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/lib/Analysis/ObjCARCInstKind.cpp:(function llvm::objcarc::GetFunctionClass(llvm::Function const*)): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/tools/clang/lib/StaticAnalyzer/Core/CallEvent.cpp:(function clang::ento::CXXDestructorCall* clang::ento::CallEventManager::create<clang::ento::CXXDestructorCall, clang::CXXDestructorDecl const*, clang::Stmt const*, clang::ento::MemRegion const*, bool>(clang::CXXDestructorDecl const*, clang::Stmt const*, clang::ento::MemRegion const*, bool, llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>, clang::LocationContext const*)): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/lib/Analysis/ObjCARCInstKind.cpp:(function llvm::objcarc::GetFunctionClass(llvm::Function const*)): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/lib/Analysis/ObjCARCInstKind.cpp:(function llvm::objcarc::GetFunctionClass(llvm::Function const*)): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/lib/Analysis/ObjCARCInstKind.cpp:(function llvm::objcarc::GetFunctionClass(llvm::Function const*)): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/lib/Analysis/ObjCARCInstKind.cpp:(function llvm::objcarc::GetFunctionClass(llvm::Function const*)): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/lib/Analysis/ObjCARCInstKind.cpp:(function llvm::objcarc::GetFunctionClass(llvm::Function const*)): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: /home/yawmoo/Desktop/clfs/sources/llvm/lib/Analysis/ObjCARCInstKind.cpp:(function llvm::objcarc::GetFunctionClass(llvm::Function const*)): relocation R_ARM_CALL out of range /home/yawmoo/Desktop/clfs/llvm-cross-tools-lld/bin/ld.lld: error: too many errors emitted, stopping now (use -error-limit=0 to see all errors) clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation) tools/clang/tools/driver/CMakeFiles/clang.dir/build.make:227: recipe for target 'bin/clang-5.0' failed make[2]: *** [bin/clang-5.0] Error 1 CMakeFiles/Makefile2:11670: recipe for target 'tools/clang/tools/driver/CMakeFiles/clang.dir/all' failed make[1]: *** [tools/clang/tools/driver/CMakeFiles/clang.dir/all] Error 2 Makefile:149: recipe for target 'all' failed make: *** [all] Error 2 yawmoo at yawmoo-MRNM3AP:~/Desktop/clfs/sources/llvm-build-native-with-lld$> > Peter > > On 27 June 2017 at 11:47, Alessandro Pistocchi via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> On 26 Jun 2017, at 16:25, Rui Ueyama <ruiu at google.com> wrote: >> >> On Sun, Jun 25, 2017 at 6:40 AM, Alessandro Pistocchi via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> >>> Hi, >>> >>> I am trying to build a completely GNU free linux toolchain for the >>> raspberry pi. >>> >>> I successfully managed to compile llvm and clang for armv7 hard float ( >>> both as a cross compiler and as a native compiler ) together with the >>> following: >>> >>> Llvm with clang and lld >>> Clang builtins >>> Musl libc >>> libc++, libc++abi, libunwind >>> >>> All works well with the only thing to notice being the need to use -fPIC >>> in order to access some library functions when my own c/c++ programs access >>> those functions. >>> >>> The fact seems to be that musl libc exports some symbols as protected ( >>> probably correctly ) and lld ( probably correctly ) says it cannot preempt >>> those symbols. >>> For this reason I seem to have to use -fPIC in the C and CXX flags but >>> everything seems to work ok. >> >> >> Is this the same problem mentioned in >> https://bugs.llvm.org/show_bug.cgi?id=32425? >> >> >> My aim is to build llvm+clang+lld using llvm+clang+lld on arm ( using musl, >> libc++, libc++abi, libunwind and the clang builtins, no gcc runtime at all >> ). >> >> I think the fact that lld cannot preempt some symbols without using -fPIC is >> similar to the problem mentioned in >> https://bugs.llvm.org/show_bug.cgi?id=32425 . >> >> However I am not particularly bothered at this stage about having to use >> -fPIC. That would be fine. >> >> What I am struggling with is that having to use -fPIC is in conflict with >> the arm backend issue that creates bad relocations when building clang with >> -fPIC as mentioned in http://llvm.org/docs/HowToCrossCompileLLVM.html and so >> the build with -fPIC fails when building the clang binary. >> >> Regarding https://bugs.llvm.org/show_bug.cgi?id=32425 , please notice that >> contrary to what is reported there I definitely can build and execute a C >> hello world program without having to use -fPIC. >> >> It is only some symbols from musl that cannot be preempted by lld, not all >> of them. >> >> Unfortunately, when building llvm+clang+lld quite a few of those symbols are >> explicitly looked for by cmake and not found unless I use -fPIC. >> >> If I go ahead and build without using -fPIC then the build fails because it >> cannot preempt those symbols. >> >> It looks like a paradox to me and I think the solution would be to fix the >> fact that the arm backend does not like -fPIC as mentioned in >> http://llvm.org/docs/HowToCrossCompileLLVM.html . While it is probably >> correct that lld says it cannot preempt protected symbols, the arm backend >> issue is a known issue. >> >> >>> >>> Then I tried to use this compiler ( both the cross compiler and the native >>> compiler ) to compile llvm + clang + lld ( I want to have the toolchain >>> built with itself, again without any GNU software involved ) but when >>> building the clang executable I ran into the arm relocation problems >>> mentioned here in the “Hacks” section when using -fPIC: >>> http://llvm.org/docs/HowToCrossCompileLLVM.html . >>> On the other hand, I seem to need -fPIC otherwise cmake fails to find some >>> libc functions such as futimes/futimens and many others. If I use -fPIC for >>> CFLAGS but not for CXXFLAGS then cmake finds those symbols but then >>> obviously fails at a later stage with lld unable to preempt those symbols. >>> >>> This seems to be a conflict I cannot solve without someone within the llvm >>> team fixing the arm relocation problem. Is there any estimate of when this >>> could happen? I am happy to spend the time testing any solutions by building >>> my own toolchain until it succeeds. Or is there any other solution? >>> >>> Thank you, >>> Alex >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>
Rafael Avila de Espindola via llvm-dev
2017-Jun-30 00:49 UTC
[llvm-dev] Building llvm with clang and lld on arm and the llvm arm backend relocation on position independent code
Peter Smith via llvm-dev <llvm-dev at lists.llvm.org> writes:> Hello Alessandro, > > Despite the statement in the HowToCrossCompileLLVM guide "If you’re > using Clang as the cross-compiler, there is a problem in the LLVM ARM > back-end that is producing absolute relocations on > position-independent code (R_ARM_THM_MOVW_ABS_NC), so for now, you > should disable PIC:" I can't find an existing upstream PR or any > record that this has been fixed. If the ARM backend is still producing > an R_ARM_THM_MOVW_ABS_NC relocation when -fpic is given as an option > then it would be great to get a small reproducible example in a new > PR, or if there is one already to update it.I am pretty sure we don't try using movw/movt with pic on ELF: https://bugs.llvm.org/show_bug.cgi?id=28229 Cheers, Rafael