[Bug gold/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 --- Comment #14 from H.J. Lu --- (In reply to Cary Coutant from comment #13) > (In reply to H.J. Lu from comment #12) > > Since there is no need to prepare for PLT branch on x86-64, we can treat > > PC32 relocation with branch as PLT32 relocation. I posted a patch for ld: > > > > https://sourceware.org/ml/binutils/2018-02/msg00065.html > > What do you mean by "prepare for PLT branch"? On i386, there are 2 types of PLTs, PIC and non-PIC. PIE and shared objects must use PIC PLT. To use PIC PLT, you need to load _GLOBAL_OFFSET_TABLE_ into EBX first. There is no need for that on x86-64. > It looks like your patch examines the opcode(s) preceding the relocated > value to determine whether it's a branch or not. How is this safe? It seems > fragile to me. In addition, it requires the linker to read section contents > while scanning relocations, which is not normally necessary, and will slow > the linker down significantly -- we normally don't need to read most > sections' contents until it's time to apply relocations. > > If your argument is that you can always treat PC32 relocations on branches > as if they were PLT32 relocations, why not just have the compiler emit PLT32 > relocations in the first place? Yes, this patch does that: https://sourceware.org/ml/binutils/2018-02/msg00074.html -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 --- Comment #13 from Cary Coutant --- (In reply to H.J. Lu from comment #12) > Since there is no need to prepare for PLT branch on x86-64, we can treat > PC32 relocation with branch as PLT32 relocation. I posted a patch for ld: > > https://sourceware.org/ml/binutils/2018-02/msg00065.html What do you mean by "prepare for PLT branch"? It looks like your patch examines the opcode(s) preceding the relocated value to determine whether it's a branch or not. How is this safe? It seems fragile to me. In addition, it requires the linker to read section contents while scanning relocations, which is not normally necessary, and will slow the linker down significantly -- we normally don't need to read most sections' contents until it's time to apply relocations. If your argument is that you can always treat PC32 relocations on branches as if they were PLT32 relocations, why not just have the compiler emit PLT32 relocations in the first place? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #12 from H.J. Lu --- Since there is no need to prepare for PLT branch on x86-64, we can treat PC32 relocation with branch as PLT32 relocation. I posted a patch for ld: https://sourceware.org/ml/binutils/2018-02/msg00065.html -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 --- Comment #11 from Rafael Ávila de Espíndola --- (In reply to Cary Coutant from comment #10) > The "official" or "canonical" PLT entry is the one that serves as the > address of the function throughout the program. OK, so we were talking about the same plt entry. > If you make the function protected in your shared library, I think the PIC > sequence to get its address will always load the address of the function > itself, while the PC32 relocation in the main program will have no > alternative but to load the address of its own PLT entry. (Gnu ld will > refuse to build a shared library with a PC32 ref to a protected symbol, but > gold will build it.) That is what I would expect. Using a PLT entry in the main executable as the canonical PLT entry should work in the same cases where a copy relocation works: The use is in the main program and the definition has default visibility. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 --- Comment #10 from Cary Coutant --- The "official" or "canonical" PLT entry is the one that serves as the address of the function throughout the program. If you make the function protected in your shared library, I think the PIC sequence to get its address will always load the address of the function itself, while the PC32 relocation in the main program will have no alternative but to load the address of its own PLT entry. (Gnu ld will refuse to build a shared library with a PC32 ref to a protected symbol, but gold will build it.) That's probably not the only way to break function pointer comparison. I'm just really leery of treating this relocation as PIC-/PIE-compatible. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=22791
--- Comment #9 from Rafael Ávila de Espíndola ---
(In reply to Cary Coutant from comment #8)
> (In reply to Rafael Ávila de Espíndola from comment #5)
> > (In reply to Cary Coutant from comment #4)
> > > This would be fine if we knew for a fact that the relocation is on a call
> > > instruction. The problem is that R_X86_64_PC32 isn't always a call
> > > instruction.
> >
> > It still works. The library will see the address of the got entry.
>
> Which won't necessarily be the "official" PLT entry. Function point
> comparison may break.
Not sure what you mean by "official". The testcase I uploaded computes address
of an external function foo with
movslq bar(%rip), %rax
leaqbar(%rip), %rdi
addq%rax, %rdi
...
.data
.p2align3
bar:
.long foo - .
and in a shared library foo is defined as
void foo(void *bar) {
printf("%p %p\n", bar, foo);
}
I always get the same value printed twice.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 --- Comment #8 from Cary Coutant --- (In reply to Rafael Ávila de Espíndola from comment #5) > (In reply to Cary Coutant from comment #4) > > This would be fine if we knew for a fact that the relocation is on a call > > instruction. The problem is that R_X86_64_PC32 isn't always a call > > instruction. > > It still works. The library will see the address of the got entry. Which won't necessarily be the "official" PLT entry. Function point comparison may break. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 --- Comment #7 from Rafael Ávila de Espíndola --- (In reply to Rafael Ávila de Espíndola from comment #5) > (In reply to Cary Coutant from comment #4) > > This would be fine if we knew for a fact that the relocation is on a call > > instruction. The problem is that R_X86_64_PC32 isn't always a call > > instruction. > > It still works. The library will see the address of the got entry. > > I will upload a testcase. s/got/plt/ -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 --- Comment #6 from Rafael Ávila de Espíndola --- Created attachment 10787 --> https://sourceware.org/bugzilla/attachment.cgi?id=10787=edit testcase that prints the address of a function -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 H.J. Lu changed: What|Removed |Added Summary|Don't error when a -pie |Don't error when a -pie |executable uses a shared|executable uses a shared |function without a got |function without PIC/PIE ||relocation -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
