[llvm-dev] lld dynamic relocation creation issue

Adhemerval Zanella via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 3 05:50:25 PST 2016


Hi all,

Working on lld aarch64 support I came across an issue where I am not sure which
would be best design approach to solve.

The aarch64 R_AARCH64_ABS64 relocation for PIC/PIE build requires a dynamic
relocation (R_AARCH64_RELATIVE) with the value set as the addend of the 
relocation.  For instance, when linking the crtbeginS.o which contains:

Relocation section '.rela.init_array' at offset 0xd28 contains 1 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000000  000200000101 R_AARCH64_ABS64   0000000000000000 .text + d4

The resulting dynamic relocation on the shared object should be:

Relocation section '.rela.dyn' at offset 0x548 contains 10 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000010dc0  000000000403 R_AARCH64_RELATIV                    7a8

Where 0x7a8 (dynamic relocation r_addend) points to a function at
.text segment (in this case frame_dummy).

I am trying to made this on lld, but current step sequence is:

- Write::run
  \_ Write::createSections
     \_ Write::scanRelocs
        \_ Write::addReloc // Dynamic Relocation creation
  \_ Write::writeSections
     \_ OutputSectionBase::writeTo
        \_ InputSection::writeTo
           \_ InputSection::relocate
              \_ TargetInfo::relocateOne 

The problem is only at TargetInfo::relocate the target (aarch64) will see
that the relocation is a R_AARCH64_ABS64 one and thus will need to create
a dynamic R_AARCH64_RELATIVE relocation.

Also from comments at ELF/Writer.cpp:243 I noted that scanRelocs is done 
early as a design choice.  So I am not sure if it would be best to follow
the second idea of the comment (and do the scan later *after* the relocations
is computed) or if it would be better to allow the TargetInfo add a scan
phase to handle such things (as other linker does).

Suggestions, tips, advices?



More information about the llvm-dev mailing list