Generate the R_AARCH64_COPY relocation for non-GOT relocations,
which reference object symbols from shared libraries.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
ELF/Target.cpp | ||
---|---|---|
917–919 ↗ | (On Diff #41303) | These are GOT-relative relocations. Do you need to create copy relocations for them? |
ELF/Target.cpp | ||
---|---|---|
917–919 ↗ | (On Diff #41303) | They are in the same table "4-6, Data relocations" and in the same section "4.6.5 Static Data relocations" as R_AARCH64_ABS* in the following spec: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf. Can you hint me for some other specs? |
ELF/Target.cpp | ||
---|---|---|
917–919 ↗ | (On Diff #41303) | I'm sorry if that's not clear, I pointed out PREL relocations. (I selected these three lines on Phab, but Phab includes plus/minus one lines to the diff in addition to the selection I made on the web UI.) |
ELF/Target.cpp | ||
---|---|---|
917–919 ↗ | (On Diff #41303) | Yes, I've commented the same lines, about _PREL* relocs. I have to admit that I haven't found a real sample to check all of them. I filled the list basing mostly on my understanding of specs. I'll really appreciate any hints and samples. |
ELF/Target.cpp | ||
---|---|---|
917–919 ↗ | (On Diff #41303) | Since they are GOT-relative, all code that uses these relocations should always reference data through GOT, so no need to create copy relocations. Gold doesn't create copy relocations for them too. |
ELF/Target.cpp | ||
---|---|---|
917–919 ↗ | (On Diff #41303) | The spec says that they are position-relative, not GOT-relative. http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf. |
ELF/Target.cpp | ||
---|---|---|
917–919 ↗ | (On Diff #41303) | Hm, I may have misread the spec. But could you take a look at gold? It seems to me that they do not create copy relocations for them. |
ELF/Target.cpp | ||
---|---|---|
917–919 ↗ | (On Diff #41303) | Gold doesn't produce COPY relocations in that case. It only makes PLT entry if some conditions met. And they have a comment "This is used to fill the GOT absolute address". |
ELF/Target.cpp | ||
---|---|---|
917–919 ↗ | (On Diff #41303) | Doesn't that mean we shouldn't create COPY relocations for PREL relocations, no? Or, are we different from gold? |
ELF/Target.cpp | ||
---|---|---|
917–919 ↗ | (On Diff #41303) | I've not finished my investigations with gold yet. I don't feel like we should just copy their behavior, I prefer to understand it first. |
ELF/Target.cpp | ||
---|---|---|
917–919 ↗ | (On Diff #41303) | I completely agree. |
- Removed R_AARCH64_PREL{16,32,64} relocations from the list of sources for COPY relocation.
- Sorted relocation codes.
- Neither ld, nor gold create a COPY relocation for a source PREL relocation.
- For me, it's hard to imagine using a PREL relocation against an external preemtible object symbol.
So, nobody probably will suffer.
We have another difference from gold, concerning ABS relocations. They don't generate a COPY relocation if an ABS relocation targets a r/w segment; in this case, they just preserve the original relocation. Everything works fine because the dynamic linker from glibc supports ABS{32,64} relocations in addition to the standard dynamic relocations. I am not sure about other dynamic linkers, in particular, on FreeBSD, and anyway ld generates COPY relocations in that situation. Thus, I decided to generate COPY relocations in that case.
- Add check for the type of the output because COPY relocations shouldn't be created for shared objects.
LGTM
ELF/Target.cpp | ||
---|---|---|
942–943 ↗ | (On Diff #41632) | You may want to move this at beginning of this function? |