[Bug gas/23997] PLT32 relocation is off by 4
https://sourceware.org/bugzilla/show_bug.cgi?id=23997 --- Comment #10 from H.J. Lu --- (In reply to Ruslan Nikolaev from comment #9) > (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? Yes. -- 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 gas/23997] PLT32 relocation is off by 4
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 on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23997] PLT32 relocation is off by 4
https://sourceware.org/bugzilla/show_bug.cgi?id=23997 --- Comment #7 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b9519cfe9828b9ee5a73e74b4be83d46f33e6886 commit b9519cfe9828b9ee5a73e74b4be83d46f33e6886 Author: H.J. Lu Date: Wed Dec 19 12:21:56 2018 -0800 x86: Properly handle PLT expression in directive For PLT expressions, we should subtract the PLT relocation size only for jump instructions. Since PLT relocations are PC relative, we only allow "symbol@PLT" in PLT expression. gas/ PR gas/23997 * config/tc-i386.c (x86_cons): Check for invalid PLT expression. (md_apply_fix): Subtract the PLT relocation size only for jump instructions. * testsuite/gas/i386/reloc32.s: Add test for invalid PLT expression. * testsuite/gas/i386/reloc64.s: Likewise. * testsuite/gas/i386/ilp32/reloc64.s: Likewise. * testsuite/gas/i386/reloc32.l: Updated. * testsuite/gas/i386/reloc64.l: Likewise. * testsuite/gas/i386/ilp32/reloc64.l: Likewise. ld/ PR gas/23997 * testsuite/ld-i386/i386.exp: Run PR gas/23997 test. * testsuite/ld-x86-64/x86-64.exp: Likewise. * testsuite/ld-x86-64/pr23997a.s: New file. * testsuite/ld-x86-64/pr23997b.c: Likewise. * testsuite/ld-x86-64/pr23997c.c: Likewise. -- 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 gas/23997] PLT32 relocation is off by 4
https://sourceware.org/bugzilla/show_bug.cgi?id=23997 H.J. Lu changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED Target Milestone|--- |2.32 --- Comment #8 from H.J. Lu --- Fixed for 2.32. -- 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 gas/23997] PLT32 relocation is off by 4
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 - . seems to always generate correct offset (even for PIC). For both i386 and x86-64, clang/LLVM generated correct offset in either case. So, I think, it may present some problem as i386 and x86_64 assembly code is often (at least partially) shared. -- 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 gas/23997] PLT32 relocation is off by 4
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 bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23997] PLT32 relocation is off by 4
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: specifies the offset to the PLT entry of symbol name from the > current code > location. > > "name@PLT - ." has undefined behavior. Can you just use name@PLT for both > PIC and non-PIC codes? > It is possible but see below. > > want to use this construction. I checked LLVM/clang; it compiles correct > > output in both cases. > > This isn't relevant. I guess, I do not have a very strong opinion about that. But my concern is that the generated relocation is off by 4 which is not clear why; I discovered that by a mere chance. The LLVM behavior is probably more intuitive here but at the very least it would be good to error out rather than just silently generate an incorrect 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
[Bug gas/23997] PLT32 relocation is off by 4
https://sourceware.org/bugzilla/show_bug.cgi?id=23997 --- Comment #3 from H.J. Lu --- (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: specifies the offset to the PLT entry of symbol name from the current code location. "name@PLT - ." has undefined behavior. Can you just use name@PLT for both PIC and non-PIC codes? > want to use this construction. I checked LLVM/clang; it compiles correct > output in both cases. This isn't relevant. -- 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 gas/23997] PLT32 relocation is off by 4
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 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 gas/23997] PLT32 relocation is off by 4
https://sourceware.org/bugzilla/show_bug.cgi?id=23997
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2018-12-18
CC||hjl.tools at gmail dot com
Ever confirmed|0 |1
--- Comment #1 from H.J. Lu ---
(In reply to Ruslan Nikolaev from comment #0)
> 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 example for some -fpic -mcmodel=small compiled code.
> There is an external function func() for which we store a relative reference
> to the corresponding @plt stub in a 32-bit variable.
>
> The following seems to generate correct offsets (@plt is already relative, so
> we can probably specify it directly):
>
> void func(void);
>
> asm("a: .long func@plt");
>
> extern int a;
>
> int geta()
> {
> return a;
> }
>
> gcc -Wall -O2 -c -fpic test.c
>
> yields
>
> RELOCATION RECORDS FOR [.text]:
> OFFSET TYPE VALUE
> R_X86_64_PLT32func
> 0013 R_X86_64_REX_GOTPCRELX a-0x0004
>
> However, if we change asm("a: .long func@plt") to asm("a: .long func@plt -
> .")
> the generated code is very weird and is off by 4:
@PLT is PC relative. Why do you want to use "func@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 gas/23997] PLT32 relocation is off by 4
https://sourceware.org/bugzilla/show_bug.cgi?id=23997 Florian Weimer changed: What|Removed |Added CC||fweimer at redhat dot com -- 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
