[llvm-dev] lld dynamic relocation creation issue

[Adhemerval Zanella via llvm-dev]

On 03-02-2016 19:50, Rui Ueyama wrote:
> We are refactoring the relocation generation code, but currently Writer::scanReloc adds relocation entries for the dynamic relocations. If "Out<ELFT>::RelaDyn->addReloc({&C, &RI});" is not called for your relocation, then no dynamic relocation will be created for that.
> 
> What do you currently get? You didn't see any dynamic relocations for R_AACH_ABS64 relocs, do you?
> 

Current there is no dynamic relocation creation for R_AARCH64_ABS64, which leads
to invalid shared objects due invalid relocation against .{init,fini}_array.

If I specifically set needsDynRelative to return true for R_AARCH64_ABS64 in
PIC/PIE and set RelativeRel to the expected type (R_AARCH64_RELATIVE) I do see
dynamic relocation being generated, with wrong target:

Relocation section '.rela.dyn' at offset 0x4d8 contains 10 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000002000  000000000403 R_AARCH64_RELATIV                    0

Disassembly of section .init_array:

0000000000002000 <__frame_dummy_init_array_entry>:
    2000:       000010e8        .word   0x000010e8
    2004:       00000000        .word   0x00000000

00000000000010e8 <frame_dummy>:
    10e8:       a9bf7bfd        stp     x29, x30, [sp,#-16]!

The R_AARCH64_ABS64 relocation will be place in '.init_array' section, but its
value '0x10e8' (which points to the frame_dummy) should be used instead as the
r_addend of the R_AARCH64_RELATIVE (because libc itself does not consider the
value of the relocation itself, just the map address plus the dynamic relocation
addend value).

That's why I need to instruct a dynamic creation not in scanRolocs, but rather
in relocateOne with the correct value of R_AARCH64_ABS64 to use it as the 
addend of the dynamic R_AARCH64_RELATIVE. And my doubt is exactly on how to
design it on lld, where all the dynamic relocation are only create before
any actual relocation computation.

My first idea is to add a method 'InputSectionBase<ELFT>::addDynamicReloc'
and then pass the InputSection on TargetInfo::relocateOne, but I am not
sure if it would desirable.


> On Wed, Feb 3, 2016 at 5:50 AM, Adhemerval Zanella via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
>     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?
> 
>     _______________________________________________
>     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
> 
>