[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