https://sourceware.org/bugzilla/show_bug.cgi?id=27169
--- Comment #14 from H.J. Lu ---
Just to be clear. Some i386 shared libraries are compiled without
-fPIC on purpose to improve performance. When ld sees R_386_PC32
of an undefined symbol in a shared library, it creates a dynamic
R_386_PC32 re
https://sourceware.org/bugzilla/show_bug.cgi?id=27169
H.J. Lu changed:
What|Removed |Added
Resolution|NOTABUG |WONTFIX
--- Comment #13 from H.J. Lu ---
T
https://sourceware.org/bugzilla/show_bug.cgi?id=27169
--- Comment #12 from H.J. Lu ---
i386 is legacy. Let's leave it alone.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=27169
--- Comment #11 from Fangrui Song ---
I agree that the assembler needs a notation to differentiate
R_386_PC32/R_386_PLT32 branches. So perhaps this should be implemented in GCC
instead: for a default visibility function declaration, emit `call
https://sourceware.org/bugzilla/show_bug.cgi?id=27169
--- Comment #10 from Fangrui Song ---
(In reply to H.J. Lu from comment #9)
> ld uses R_386_PC32 to tell if call site supports PIC PLT. Calling an IFUNC
> function in static PIE requires PLT. If call site doesn't support PIC PLT,
> linker wil
https://sourceware.org/bugzilla/show_bug.cgi?id=27169
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=27169
--- Comment #8 from H.J. Lu ---
(In reply to Fangrui Song from comment #7)
> Applied your R_386_PLT32 patch.
>
> # of unexpected failures6
>
> make -C Debug check-ld RUNTESTFLAGS=ld-shared/shared.exp # passed for me.
>
You need to
https://sourceware.org/bugzilla/show_bug.cgi?id=27169
--- Comment #7 from Fangrui Song ---
Applied your R_386_PLT32 patch.
# of unexpected failures6
make -C Debug check-ld RUNTESTFLAGS=ld-shared/shared.exp # passed for me.
ld/testsuite/ld-i386/pr20515.d is an expected failure due to no
https://sourceware.org/bugzilla/show_bug.cgi?id=27169
--- Comment #6 from H.J. Lu ---
Created attachment 13109
--> https://sourceware.org/bugzilla/attachment.cgi?id=13109&action=edit
A patch to generate R_386_PLT32
I tried this patch when I made:
commit bd7ab16b4537788ad53521c45469a1bdae84ad4
https://sourceware.org/bugzilla/show_bug.cgi?id=27169
--- Comment #5 from Fangrui Song ---
Sorry
# a.s
.globl main
main:
call puts
# b.s
.globl main
main:
call puts@plt
gcc -m32 -no-pie a.s -o a -fuse-ld=bfd
gcc -m32 -no-pie b.s -o b -fuse-ld=bfd
do not have instruction difference.
--
Yo
https://sourceware.org/bugzilla/show_bug.cgi?id=27169
--- Comment #4 from Fangrui Song ---
(In reply to H.J. Lu from comment #3)
> (In reply to Fangrui Song from comment #2)
> > (In reply to H.J. Lu from comment #1)
> > > Since i386 doesn't have IP-relative addressing, non-PIC PLT is different
>
https://sourceware.org/bugzilla/show_bug.cgi?id=27169
--- Comment #3 from H.J. Lu ---
(In reply to Fangrui Song from comment #2)
> (In reply to H.J. Lu from comment #1)
> > Since i386 doesn't have IP-relative addressing, non-PIC PLT is different
> > from PIC PLT. Using R_386_PLT32 for "call/jmp
https://sourceware.org/bugzilla/show_bug.cgi?id=27169
--- Comment #2 from Fangrui Song ---
(In reply to H.J. Lu from comment #1)
> Since i386 doesn't have IP-relative addressing, non-PIC PLT is different
> from PIC PLT. Using R_386_PLT32 for "call/jmp foo" isn't appreciate.
I know that this is
https://sourceware.org/bugzilla/show_bug.cgi?id=27169
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #1 f
https://sourceware.org/bugzilla/show_bug.cgi?id=27169
Fangrui Song changed:
What|Removed |Added
Target||i386-*
--
You are receiving this mail
15 matches
Mail list logo
