Building llvm with clang and lld on arm and the llvm arm backend relocation on position independent code

Project Infrastructure LLVM Dev List Archives
1

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.

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

2

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
32425 – Regression with Musl after adding support for outputting to /dev/null?

3

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.

4

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

5

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@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@yawmoo-MRNM3AP:~/Desktop/clfs/sources/llvm-build-native-with-lld$

6

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
33612 – ARM: Add range thunk support to avoid relocation R_ARM_THM_CALL out of range 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

7

Oh, so it looks like I hit a bit of a wall there :slight_smile: 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?

8

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

9

Cool thanks I'll give it a go :slight_smile:

10

I've successfully used Peter's patches to get past those relocation errors.

    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

11

Cool that looks exciting thanks :slight_smile:

12

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 )

13

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 ⚙ D34634 [LLD][ELF] Full patch for range thunks (not for review) which contains all of Peter's
patches, but it's not going to rebase cleanly once the individual patches
start going in.

    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 )

14

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

15

Peter Smith via llvm-dev <llvm-dev@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

16

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 ⚙ D34634 [LLD][ELF] Full patch for range thunks (not for review)
this morning, it might be worth trying that if you are seeing
problems.

Peter

17

Hi Rafael,

The error was R_ARM_CALL, not R_ARM_THM_MOVW_ABS_NC.

Thanks,
A

18

Thanks a lot for helping me out, I managed to compile it as a cross compiler and now building the native one :slight_smile:

Will let you know if there are any other issues.

19

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?

20

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