[PATCH] D19645: Skip scanRelocs for non-alloc sections.
Rafael Ávila de Espíndola via llvm-commits
llvm-commits at lists.llvm.org
Thu Apr 28 10:02:06 PDT 2016
rafael accepted this revision.
rafael added a comment.
This revision is now accepted and ready to land.
LGTM with the name changed and the IsAlloc bool replaced with false.
================
Comment at: ELF/InputSection.cpp:230
@@ +229,3 @@
+// This function applies relocations to sections without SHF_ALLOC bit.
+// Such sections are never mapped to memory at runtime. Debug section is
+// an example. Relocations in non-alloc sections are much easier to
----------------
Debug section is -> Debug sections are.
================
Comment at: ELF/InputSection.h:222
@@ +221,3 @@
+ template <class RelTy>
+ void relocateNative(uint8_t *Buf, llvm::ArrayRef<RelTy> Rels);
+
----------------
ruiu wrote:
> rafael wrote:
> > Native?
> Do you have any suggestions for better name?
Maybe just relocateNonAlloc?
================
Comment at: test/ELF/relocation-non-alloc.s:36
@@ -35,3 +35,3 @@
// CHECK-NEXT: SectionData (
-// CHECK-NEXT: 0000: 00100000 00000000 00000000 00000000
+// CHECK-NEXT: 0000: 00100000 00000000 00100000 00000000
// CHECK-NEXT: )
----------------
ruiu wrote:
> rafael wrote:
> > Is the change expected?
> Yes. BFD and gold both produces this pattern rather than the old one. This is a test to produce a DSO file with a non-alloc section pointing to an interruptible symbol. This seems to be unrealistic test case. LLD previously handle interruptible symbols addresses as 0 because it can change at runtime, but GNU linkers don't seem to bother it.
OK, I think I see what is going on.
For preemptable symbols in alloc sections we have to create a dynamic relocation. Having created one, we know the dynamic linker will take care of everything and we don't need to do anything else.
I am not sure if these show up in practice in non alloc sections, but it seems reasonable to have them point to the symbol in the file we are producing since there will be no dynamic relocation.
http://reviews.llvm.org/D19645
More information about the llvm-commits
mailing list