[Bug gold/22868] Gold does not select proper symbol visibility when used with LLVM gold-plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=22868 --- Comment #9 from Nick Clifton --- Created attachment 10915 --> https://sourceware.org/bugzilla/attachment.cgi?id=10915&action=edit Recording Hi Cary, Here is a recording of the test case from PR 22994. I hope that it helps. Cheers Nick -- 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/22868] Gold does not select proper symbol visibility when used with LLVM gold-plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=22868 --- Comment #10 from georgerim at gmail dot com --- Created attachment 10916 --> https://sourceware.org/bugzilla/attachment.cgi?id=10916&action=edit Requested record file And here is mine record file for this bug. -- 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 ld/23000] TLSDESC_PLT is incompatible with IBT
https://sourceware.org/bugzilla/show_bug.cgi?id=23000 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The binutils-2_30-branch branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=963e88c631ad5878d70d055fd8597c83279efe66 commit 963e88c631ad5878d70d055fd8597c83279efe66 Author: H.J. Lu Date: Mon Mar 26 03:57:01 2018 -0700 x86-64: Add ENDBR64 to the TLSDESC PLT entry The TLSDESC entry in a lazy procedure linkage table is called indirectly with "callq *(%rax)". This patch adds an ENDBR64 to support indirect branch tracking in Intel CET. The TLSDESC PLT entry now looks like: 0xf3, 0x0f, 0x1e, 0xfa, /* endbr64 */ 0xff, 0x35, 8, 0, 0, 0, /* pushq GOT+8(%rip) */ 0xff, 0x25, 16, 0, 0, 0 /* jmpq *GOT+TDG(%rip) */ The BND prefix isn't needed since MPX isn't used for TLSDESC. bfd/ PR ld/23000 * elf64-x86-64.c (elf_x86_64_finish_dynamic_sections): Add ENDBR64 to the TLSDESC PLT entry. ld/ PR ld/23000 * testsuite/ld-x86-64/tlsdesc.pd: Updated. (cherry picked from commit bf54968b128a2133174d81c438d402ecfaf83042) -- 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 ld/23000] TLSDESC_PLT is incompatible with IBT
https://sourceware.org/bugzilla/show_bug.cgi?id=23000 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |2.31 --- Comment #3 from H.J. Lu --- Fixed for 2.31 and 2.30 branch. -- 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/22500] make -k check-gold errors in passing option
https://sourceware.org/bugzilla/show_bug.cgi?id=22500 Vladislav Ivanishin changed: What|Removed |Added CC||vlad at ispras dot ru --- Comment #2 from Vladislav Ivanishin --- I experienced the same problem with gold built from source (today's master branch). You have to pass --enable-plugins to configure for gold to recognize --plugin* options. Here's binutils-gdb configured with `--enable-gold --enable-plugins`: $ gold/ld-new -plugin plug gold/ld-new: error: plug: could not load plugin library: plug: cannot open shared object file: No such file or directory gold/ld-new: fatal error: no input files (This is a correct diagnostic.) And here's the same revision configured with just `--enable-gold`: $ gold/ld-new -plugin plug gold/ld-new: error: cannot open plug: No such file or directory gold/ld-new: error: cannot find -lugin Also note that the diagnostic emitted by ld.bfd is the same for both configurations: $ ld/ld-new -plugin plug ld/ld-new: plug: error loading plugin: plug: cannot open shared object file: No such file or directory -- 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 ld/22970] Add support for R_AARCH64_TLSLE_LDST8_TPREL_LO12 relocation.
https://sourceware.org/bugzilla/show_bug.cgi?id=22970 --- Comment #3 from Peter Smith --- Hello Nick, I've been able to try out the patch. It looks like it is doing what I'd expect for the R_AARCH64_TLSLE_LDST8_TPREL_LO12_NC relocation. When I went back to the original LLVM patch, I tried the example and got a missing relocation error. It looks like my PR was incomplete; I missed out: R_AARCH64_TLSLE_LDST16_TPREL_LO12_NC R_AARCH64_TLSLE_LDST32_TPREL_LO12_NC R_AARCH64_TLSLE_LDST64_TPREL_LO12_NC These correspond to the halfword, 32-bit and 64-bit word load instructions (the LDST8 is the byte load instruction). My apologies for missing these out, would it be possible to consider these as well as they could be generated by a compiler with the same llvm patch? An example to that can be assembled with clang --target=aarch64-linux-gnu generates these relocations. .text .globl _start .type _start, %function _start: mrs x8, TPIDR_EL0 add x8, x8, :tprel_hi12:var0 ldr x0, [x8, :tprel_lo12_nc:var0] add x8, x8, :tprel_hi12:var1 ldr w0, [x8, :tprel_lo12_nc:var1] add x8, x8, :tprel_hi12:var2 ldrh w0, [x8, :tprel_lo12_nc:var2] add x8, x8, :tprel_hi12:var3 ldrb w0, [x8, :tprel_lo12_nc:var3] .globl var0 .globl var1 .globl var2 .globl var3 .type var0,@object .type var1,@object .type var2,@object .type var3,@object .section.tbss,"awT",@nobits .p2align2 var0: .quad 0 .size var1, 8 var1: .word 0 .size var1, 4 var2: .hword 0 .size var2, 2 var3: .byte 0 .size var3, 1 -- 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/23002] New: [RISCV] Pseudoinstruction Call is expanded incorrectly
https://sourceware.org/bugzilla/show_bug.cgi?id=23002 Bug ID: 23002 Summary: [RISCV] Pseudoinstruction Call is expanded incorrectly Product: binutils Version: 2.29 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: sourceware at lusiardi dot de Target Milestone: --- Hello, I think I found a small issue with the replacement of the call pseudo instruction in Version 2.29.1: As input I used the following snippet: label: nop nop call label This should be an endless loop executing the nops again and again. I can confirm this behaviour with http://www.kvakil.me/venus/. Now if I feed this code to riscv64-unknown-elf-as and use riscv64-unknown-elf-objdump on the result I receive : 0: 0013nop 4: 0013nop 8: 0097auipc ra,0x0 c: 80e7jalrra Where ra is x1 and 'jalr ra' expands to 'jalr ra, ra, 0'. This is also an endless loop but only loops the call command. This seems to be wrong. I would be please to help with any further information. Regards Joachim Lusiardi -- 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/23002] [RISCV] Pseudoinstruction Call is expanded incorrectly
https://sourceware.org/bugzilla/show_bug.cgi?id=23002 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andreas Schwab --- There are relocations on the auipc insn, use objdump -r to list them. -- 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/23002] [RISCV] Pseudoinstruction Call is expanded incorrectly
https://sourceware.org/bugzilla/show_bug.cgi?id=23002 Joachim Lusiardi changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Joachim Lusiardi --- Hello, yes, there are relocations on the auipc instruction: 8: 0097auipc ra,0x0 8: R_RISCV_CALL label 8: R_RISCV_RELAX*ABS* But according to the Instruction Set Manual Version 2.2 the auipc instruction does the following: Expand the 20bit U-immediate with zeros, add it to PC and store the result in register (in this case ra). In this case this is 8 in ra. So I do not exactly know what these relocations mean, but it still seems to be an issue here. Regards Joachim -- 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/23002] [RISCV] Pseudoinstruction Call is expanded incorrectly
https://sourceware.org/bugzilla/show_bug.cgi?id=23002 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andreas Schwab --- The linker will resolve the relocation and sets the immediate operand to the correct offset. If you need help how to do assembler programming then this is not the right place to ask. -- 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/22868] Gold does not select proper symbol visibility when used with LLVM gold-plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=22868 --- Comment #11 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Cary Coutant : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0b7a4aa6ba5a144b7ce616e80e95d9ff944fec2e commit 0b7a4aa6ba5a144b7ce616e80e95d9ff944fec2e Author: Cary Coutant Date: Fri Mar 23 09:03:34 2018 -0700 Fix case where IR file provides symbol visibility but replacement file does not. In PR 22868, two IR files provide conflicting visibility for a symbol. When a def with PROTECTED visibility is seen after a def with DEFAULT visibility, gold does not override the visibility. Later, if the replacement object define the symbol with DEFAULT visibility, the symbol remains DEFAULT. This was caused by a recent change to allow multiply-defined absolute symbols, combined with the fact that the plugin framework was using SHN_ABS as the section index for placeholder symbols. The solution is to use a real (but arbitrary) section index. gold/ PR gold/22868 * plugin.cc (Sized_pluginobj::do_add_symbols): Use a real section index instead of SHN_ABS for defined symbols. * testsuite/Makefile.am (plugin_pr22868): New test case. * testsuite/Makefile.in: Regenerate * testsuite/plugin_pr22868.sh: New test script. * testsuite/plugin_pr22868_a.c: New source file. * testsuite/plugin_pr22868_b.c: New source file. -- 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/22868] Gold does not select proper symbol visibility when used with LLVM gold-plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=22868 Cary Coutant changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Cary Coutant --- Thanks for the recordings! That helped me find a stupid bug in my own attempt to reproduce the problem. Fixed on trunk; will backport to 2.30. -- 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
