[PATCH] D13566: [ELF2] PPC64 needs to delay local-call relocations until after the function-descriptor values are known

hfinkel@anl.gov via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 12 11:13:54 PDT 2015


hfinkel added inline comments.

================
Comment at: ELF/Target.cpp:401-407
@@ -400,1 +400,9 @@
+
+    if (!ForPltEntry) {
+      // If this is a local call, and we currently have the address of a
+      // function-descriptor, get the underlying code address instead.
+      auto ARI = Addr64Relocs.find(R);
+      if (ARI != Addr64Relocs.end())
+        R = ARI->second;
+    }
 
----------------
ruiu wrote:
> You may be able to eliminate the hash table by reading back previous relocatino results for R_PPC64_ADDR64 from Buf.
> 
>   if (!ForPltEntry)
>     R = read64be(Buf + R - BaseAddr);
Two problems:

 1. The relocated addresses are in a different section (and, thus, I assume, have a different base buffer pointer)

 2. If the relocation is not pointing to a function descriptor (which it might not), then we need to keep the original symbol address.

An alternative would be to be able to explicitly get the .opd section, do a bounds check (just as I do for the .plt section), and then read from its buffer. Is there a good way to do that?


================
Comment at: ELF/Target.h:96
@@ -91,1 +95,3 @@
+  // to resolve local calls.
+  mutable llvm::DenseMap<uint64_t, uint64_t> Addr64Relocs;
 };
----------------
ruiu wrote:
> Mutable memebers are not generally good, so I'd avoid using that.
The alternative is to make relocateOne non-const. Is that okay? [no need to answer this question if we don't need the map at all, as per the thread below].


http://reviews.llvm.org/D13566





More information about the llvm-commits mailing list