Adhemerval Zanella via llvm-dev
2016-Feb-03 13:50 UTC
[llvm-dev] lld dynamic relocation creation issue
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?
Rui Ueyama via llvm-dev
2016-Feb-03 21:50 UTC
[llvm-dev] lld dynamic relocation creation issue
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? On Wed, Feb 3, 2016 at 5:50 AM, Adhemerval Zanella via llvm-dev < 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 > 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/20160203/7a54f10c/attachment.html>
Adhemerval Zanella via llvm-dev
2016-Feb-04 13:11 UTC
[llvm-dev] lld dynamic relocation creation issue
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 > >