[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
Mon Jul 3 01:51:59 PDT 2017
Hello Alessandro,
That particular error message occurs when a dynamic relocation would
need to be created in the read-only part of the shared library. This
is usually indicative that some part of libobjc2 hasn't been compiled
with -fpic or contains some assembly that is making a direct reference
to a label address rather than accessing it relative to the .got.
There is an option -ztext (lld defaults to -znotext) that permits
these relocations. It maybe that if libobjc2 can be linked with other
linkers -ztext is the default, you should be able to find out if this
is the case by looking at the dynamic section with readelf -d and
looking for DF_TEXTREL or DT_TEXTREL.
Assuming lld is behaving correctly, in general it is better to find
and fix the source file that is generating these relocations as having
dynamic relocations in the read-only segment is not ideal. I suggest
finding the object that contains the R_ARM_ABS32 and tracing it back
from the object file to the source file and seeing what has generated
it. I usually use objdump -r -d for this purpose.
Hope that helps
Peter
On 1 July 2017 at 13:34, Alessandro Pistocchi <apukfreelance at gmail.com> wrote:
> Hi, I managed to build both the cross compiler and the native compiler with led.
>
> Now I am getting a "can't create dynamic relocation R_ARM_ABS32" error when building libobjc2 from gnustep and linking with lld.
>
> Any clues?
>
> Sent from my iPhone
>
>> On 30 Jun 2017, at 10:28, Peter Smith <peter.smith at linaro.org> wrote:
>>
>> At a guess that looks like your llvm and lld checkouts are not quite
>> in synch. It will be worth updating llvm and lld to top of trunk.
>>
>> I've rebased the consolidated patch https://reviews.llvm.org/D34634
>> this morning, it might be worth trying that if you are seeing
>> problems.
>>
>> Peter
>>
>>> On 29 June 2017 at 22:09, Alessandro Pistocchi <apukfreelance at gmail.com> wrote:
>>> Hi, I tried patching and rebuilding and now I get this error. Did I miss anything?
>>>
>>> /home/yawmoo/Desktop/clfs/sources/llvm/tools/lld/ELF/InputFiles.cpp:82:23: error:
>>> no matching constructor for initialization of 'llvm::DWARFDebugLine'
>>> DwarfLine.reset(new DWARFDebugLine(&Dwarf.getLineSection().Relocs));
>>> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> /home/yawmoo/Desktop/clfs/sources/llvm/include/llvm/DebugInfo/DWARF/DWARFDebugLine.h:27:7: note:
>>> candidate constructor (the implicit move constructor) not viable: no known
>>> conversion from 'const RelocAddrMap *' (aka 'const DenseMap<unsigned long,
>>> llvm::RelocAddrEntry> *') to 'llvm::DWARFDebugLine' for 1st argument
>>> class DWARFDebugLine {
>>> ^
>>> /home/yawmoo/Desktop/clfs/sources/llvm/include/llvm/DebugInfo/DWARF/DWARFDebugLine.h:27:7: note:
>>> candidate constructor (the implicit copy constructor) not viable: no known
>>> conversion from 'const RelocAddrMap *' (aka 'const DenseMap<unsigned long,
>>> llvm::RelocAddrEntry> *') to 'const llvm::DWARFDebugLine' for 1st argument
>>> /home/yawmoo/Desktop/clfs/sources/llvm/include/llvm/DebugInfo/DWARF/DWARFDebugLine.h:27:7: note:
>>> candidate constructor (the implicit default constructor) not viable:
>>> requires 0 arguments, but 1 was provided
>>> /home/yawmoo/Desktop/clfs/sources/llvm/tools/lld/ELF/InputFiles.cpp:89:34: error:
>>> no viable conversion from 'llvm::DataExtractor' to 'const
>>> llvm::DWARFDataExtractor'
>>> DwarfLine->getOrParseLineTable(LineData, 0);
>>> ^~~~~~~~
>>> /home/yawmoo/Desktop/clfs/sources/llvm/include/llvm/DebugInfo/DWARF/DWARFDataExtractor.h:20:7: note:
>>> candidate constructor (the implicit copy constructor) not viable: cannot
>>> bind base class object of type 'llvm::DataExtractor' to derived class
>>> reference 'const llvm::DWARFDataExtractor &' for 1st argument
>>> class DWARFDataExtractor : public DataExtractor {
>>> ^
>>> /home/yawmoo/Desktop/clfs/sources/llvm/include/llvm/DebugInfo/DWARF/DWARFDataExtractor.h:20:7: note:
>>> candidate constructor (the implicit move constructor) not viable: cannot
>>> bind base class object of type 'llvm::DataExtractor' to derived class
>>> reference 'llvm::DWARFDataExtractor &&' for 1st argument
>>> /home/yawmoo/Desktop/clfs/sources/llvm/include/llvm/DebugInfo/DWARF/DWARFDebugLine.h:237:66: note:
>>> passing argument to parameter 'DebugLineData' here
>>> const LineTable *getOrParseLineTable(const DWARFDataExtractor &DebugLineData,
>>> ^
>>> 2 errors generated.
>>> tools/lld/ELF/CMakeFiles/lldELF.dir/build.make:494: recipe for target 'tools/lld/ELF/CMakeFiles/lldELF.dir/InputFiles.cpp.o' failed
>>> make[2]: *** [tools/lld/ELF/CMakeFiles/lldELF.dir/InputFiles.cpp.o] Error 1
>>> CMakeFiles/Makefile2:49925: recipe for target 'tools/lld/ELF/CMakeFiles/lldELF.dir/all' failed
>>> make[1]: *** [tools/lld/ELF/CMakeFiles/lldELF.dir/all] Error 2
>>> Makefile:149: recipe for target 'all' failed
>>> make: *** [all] Error 2
>>>
>>>
>>>> On 28 Jun 2017, at 19:04, Shoaib Meenai <smeenai at fb.com> wrote:
>>>>
>>>> The bottom of the bug has the revision numbers (e.g. D34035). That one
>>>> corresponds to e.g. https://reviews.llvm.org/D34035
>>>>
>>>> There's also https://reviews.llvm.org/D34634 which contains all of Peter's
>>>> patches, but it's not going to rebase cleanly once the individual patches
>>>> start going in.
>>>>
>>>> On 6/28/17, 10:56 AM, "Alessandro Pistocchi" <apukfreelance at gmail.com> wrote:
>>>>
>>>> Sorry for the noob question: where do I get the patches?
>>>>
>>>> I can see the bug but not a link to the patches ( I don't have a login if that is the issue )
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On 28 Jun 2017, at 19:36, Shoaib Meenai <smeenai at fb.com> wrote:
>>>>>
>>>>> I've successfully used Peter's patches to get past those relocation errors.
>>>>>
>>>>> On 6/28/17, 9:36 AM, "llvm-dev on behalf of Peter Smith via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote:
>>>>>
>>>>> Yes it should cover the following relocations:
>>>>> R_ARM_CALL (ARM BL/BLX)
>>>>> R_ARM_JUMP24 (ARM B)
>>>>> R_ARM_THM_CALL (Thumb BL/BLX)
>>>>> R_ARM_THM_JUMP19 (Thumb conditional B<cc>.w)
>>>>> R_ARM_THM_JMP24 (Thumb unconditional B.w)
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>>> On 28 June 2017 at 17:31, Alessandro Pistocchi <apukfreelance at gmail.com> wrote:
>>>>>> Oh, so it looks like I hit a bit of a wall there :-) I’ll take a look thanks.
>>>>>>
>>>>>> That bug talks about R_ARM_THM_CALL which I assume are thumb related.
>>>>>>
>>>>>> Will your implementation fix also R_ARM_CALL errors?
>>>>>>
>>>>>>> On 28 Jun 2017, at 17:15, Peter Smith <peter.smith at linaro.org> wrote:
>>>>>>>
>>>>>>> Hello Alessandro,
>>>>>>>
>>>>>>> The LLD ARM port doesn't currently support range extension thunks,
>>>>>>> these are needed to extend the range of ARM branch relocations when
>>>>>>> the size of the executable instructions exceeds the maximum branch
>>>>>>> range.
>>>>>>>
>>>>>>> I have an implementation in review but it is a fairly large change so
>>>>>>> it may take some time to get through the review process, I've raised
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D33612&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=MoG8NHuM6pLu1J1B-yHnV-uqDvXgdp72ydIhDlNyQ9Q&s=RpqKAJtCInfokC4ejkvv1e1hbMx22g7c6-v8JNuzOrY&e= that has a link to the
>>>>>>> Phab reviews. If you are willing to build your own lld with additional
>>>>>>> changes, you might be able to test out those patches.
>>>>>>>
>>>>>>> Good luck
>>>>>>>
>>>>>>> Peter
>>>>>>>
>>>>>>>>> On 28 June 2017 at 17:09, Alessandro Pistocchi <apukfreelance at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D32425-3F&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=MoG8NHuM6pLu1J1B-yHnV-uqDvXgdp72ydIhDlNyQ9Q&s=NukMRJ9yTsw5j3ENYmb5P6xnVjqZDGr_RtEBf88y-aI&e=
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D32425&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=MoG8NHuM6pLu1J1B-yHnV-uqDvXgdp72ydIhDlNyQ9Q&s=9sykAqiCyyRAxvbFBkT7xc41tFV4gbqVNlLPtuZwgEo&e= .
>>>>>>>>>>
>>>>>>>>>> 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 https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_docs_HowToCrossCompileLLVM.html&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=MoG8NHuM6pLu1J1B-yHnV-uqDvXgdp72ydIhDlNyQ9Q&s=ZDjTpKgbVvk-6KPfK36_iXsQkmN0tZo-GFLmojAfWdI&e= and so
>>>>>>>>>> the build with -fPIC fails when building the clang binary.
>>>>>>>>>>
>>>>>>>>>> Regarding https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D32425&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=MoG8NHuM6pLu1J1B-yHnV-uqDvXgdp72ydIhDlNyQ9Q&s=9sykAqiCyyRAxvbFBkT7xc41tFV4gbqVNlLPtuZwgEo&e= , 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
>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_docs_HowToCrossCompileLLVM.html&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=MoG8NHuM6pLu1J1B-yHnV-uqDvXgdp72ydIhDlNyQ9Q&s=ZDjTpKgbVvk-6KPfK36_iXsQkmN0tZo-GFLmojAfWdI&e= . 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:
>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_docs_HowToCrossCompileLLVM.html&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=MoG8NHuM6pLu1J1B-yHnV-uqDvXgdp72ydIhDlNyQ9Q&s=ZDjTpKgbVvk-6KPfK36_iXsQkmN0tZo-GFLmojAfWdI&e= .
>>>>>>>>>>> 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
>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=MoG8NHuM6pLu1J1B-yHnV-uqDvXgdp72ydIhDlNyQ9Q&s=elMtK81LIlpU0bdvd9Zwk2UtgI9He36ddrHDrVDKt94&e=
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> LLVM Developers mailing list
>>>>>>>>>> llvm-dev at lists.llvm.org
>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=MoG8NHuM6pLu1J1B-yHnV-uqDvXgdp72ydIhDlNyQ9Q&s=elMtK81LIlpU0bdvd9Zwk2UtgI9He36ddrHDrVDKt94&e=
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=MoG8NHuM6pLu1J1B-yHnV-uqDvXgdp72ydIhDlNyQ9Q&s=elMtK81LIlpU0bdvd9Zwk2UtgI9He36ddrHDrVDKt94&e=
>>>>>
>>>>>
>>>>
>>>>
>>>
More information about the llvm-dev
mailing list