https://sourceware.org/bugzilla/show_bug.cgi?id=24025
--- Comment #1 from Ruslan Nikolaev ---
Just to clarify, I also mean the case when -fno-plt is specified to the
compiler
--
You are receiving this mail because:
You are on the CC list for the bug.
Assignee: unassigned at sourceware dot org
Reporter: nruslan_devel at yahoo dot com
Target Milestone: ---
One potential scenario is when code is compiled with -fpic -fvisibility=hidden
in multiple relocatable files. Then these files are combined together into a
single
https://sourceware.org/bugzilla/show_bug.cgi?id=23997
--- Comment #9 from Ruslan Nikolaev ---
(In reply to H.J. Lu from comment #8)
> Fixed for 2.32.
Thanks very much! Does it also fix the problem for i386 where an ordinary
func@plt is off by 4?
--
You are receiving this mail because:
You are
https://sourceware.org/bugzilla/show_bug.cgi?id=23997
--- Comment #6 from Ruslan Nikolaev ---
BTW, I did some further testing with i386. It seems for i386, things are also
not consistent but the other way around.
.long func@plt does not seem generate correct offset (even for PIC), but
func@plt -
https://sourceware.org/bugzilla/show_bug.cgi?id=23997
--- Comment #5 from Ruslan Nikolaev ---
or another possibility -- is to output some warning
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=23997
--- Comment #4 from Ruslan Nikolaev ---
(In reply to H.J. Lu from comment #3)
> (In reply to Ruslan Nikolaev from comment #2)
> > Sometimes when the assembly code is for both PIC and non-PIC code, you may
>
> From x86-64 psAB:
>
> name@PLT:
https://sourceware.org/bugzilla/show_bug.cgi?id=23997
--- Comment #2 from Ruslan Nikolaev ---
Sometimes when the assembly code is for both PIC and non-PIC code, you may
want to use this construction. I checked LLVM/clang; it compiles correct output
in both cases.
--
You are receiving this mail
Assignee: unassigned at sourceware dot org
Reporter: nruslan_devel at yahoo dot com
Target Milestone: ---
The bug was initially filed at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88524 (see the discussion there)
but turns out to be an assembler problem.
Consider the following
