[Bug ld/18878] _savegpr1_XXX crashes when called through a stub on POWERPC64LE
https://sourceware.org/bugzilla/show_bug.cgi?id=18878 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a4b6fadd50968ec6c1b687fe52b88bd11ff734b3 commit a4b6fadd50968ec6c1b687fe52b88bd11ff734b3 Author: Alan Modra Date: Tue Sep 1 08:56:22 2015 +0930 ppc64 out-of-line register save/restore functions Don't emit long branch or plt branch stubs to save/restore functions. Copy them instead. The problem is that plt branch stubs currently trash r12, one of the parameters to some of the save/restore functions, and there is no free register available to use instead of r12. 6f20ed8a is prerequisite for this patch. PR 18878 * elf64-ppc.c (ARRAY_SIZE): Define. Use throughout. (enum ppc_stub_type): Add ppc_stub_save_res. (struct map_stub): Add "next" and "needs_save_res". (struct ppc_link_hash_entry): Add "save_res" flag. (struct ppc_link_hash_table): Add "group". (sfpr_define): Add stub_sec param. Define symbol in stub_sec if stub_sec is non-null. Set "save_res". (save_res_funcs): Make file scope, rename from funcs. Adjust uses. (ppc64_elf_adjust_dynamic_symbol): Prohibit plt call to save_res syms. (ppc_build_one_stub): Handle ppc_stub_save_res. (ppc_size_one_stub): Set stub type to ppc_size_one_stub on finding stub for linker defined save_res sym. (group_sections): Init new fields of struct map_stub. (ppc64_elf_size_stubs): Reserve space for save/restore func copy. (ppc64_elf_build_stubs): Copy save/restore funcs to groups. Emit alias syms too. (ppc64_elf_relocate_section): Set destination for ppc_stub_save_res. -- 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/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836 --- Comment #14 from Richard Guenther --- Ok, so let me try to revive the discussion and view the needs from a "need plugin support" angle. What I need is the linker to allow the plugin to claim only a subset of the sections of the input files (those not containing the early debug LTO sections) and direct the linker to feed the remaining sections (or a specially set of marked sections) to the final link, including the possibility to have it "rename" those sections. I am "abusing" the linker script syntax to direct the linker to do the renaming and selecting the set of sections we do not claim. So with that view on the issue how would you suggest to implement this plugin-API wise? (using linker script syntax in a plugin output like the BFD linker already accepts still looks appealing to me) Also when the user passes -g0 at the link command linke we should be able to drop those early debug sections and do not link 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/18737] Wrong memory operand size for x86 GATHER/SCATTER instructions
https://sourceware.org/bugzilla/show_bug.cgi?id=18737 Alexander Fomin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |afomin.mailbox at gmail dot com --- Comment #1 from Alexander Fomin --- > However, the memory size is actually the element size, according to Intel doc Not sure what exactly you're talking about. We were not able to find anything related to a memory size directive as for Intel SDM 319433-023, August 2015. Please provide a reference to Intel SDM. Thank you. -- 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 binutils/18738] Wrong memory operand size for x86 GATHER/SCATTER instructions
https://sourceware.org/bugzilla/show_bug.cgi?id=18738 Alexander Fomin changed: What|Removed |Added Assignee|unassigned at sourceware dot org |afomin.mailbox at gmail 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
[Bug ld/18900] Unnecessary PLT entry for function pointer initialization
https://sourceware.org/bugzilla/show_bug.cgi?id=18900 --- Comment #1 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=04ebc307f9601168c165fb63aa39a676e45454b7 commit 04ebc307f9601168c165fb63aa39a676e45454b7 Author: H.J. Lu Date: Tue Sep 1 05:06:16 2015 -0700 Skip PLT for function pointer initialization We use its PLT entry to initialize function pointer at run-time. If there is no other usage for the PLT entry, we can generate run-time function pointer relocations in read-write section, which can be resolved by dynamic linker, to initialize function pointers. It avoids the extra indirect branch overhead in PLT. bfd/ PR ld/18900 * elf32-i386.c (elf_i386_link_hash_entry): Add func_pointer_refcount. (elf_i386_link_hash_newfunc): Clear func_pointer_refcount. (elf_i386_get_local_sym_hash): Likewise. (elf_i386_copy_indirect_symbol): Also copy func_pointer_refcount. (elf_i386_check_relocs): Increment func_pointer_refcount. (elf_i386_gc_sweep_hook): Decrement func_pointer_refcount. (elf_i386_allocate_dynrelocs): Don't create the PLT entry if there are only function pointer relocations which can be resolved at run-time. Keep dynanamic relocations for run-time function pointer initialization. (elf_i386_relocate_section): Copy dynamic function pointer relocations. * elf64-x86-64.c (elf_x86_64_link_hash_entry): Add func_pointer_refcount. (elf_x86_64_link_hash_newfunc): Clear func_pointer_refcount. (elf_x86_64_get_local_sym_hash): Likewise. (elf_x86_64_copy_indirect_symbol): Also copy func_pointer_refcount. (elf_x86_64_check_relocs): Increment func_pointer_refcount. (elf_x86_64_gc_sweep_hook): Decrement func_pointer_refcount. (elf_x86_64_allocate_dynrelocs): Don't create the PLT entry if there are only function pointer relocations which can be resolved at run-time. Keep dynanamic relocations for run-time function pointer initialization. (elf_x86_64_relocate_section): Copy dynamic function pointer relocations. ld/testsuite/ PR ld/18900 * ld-i386/i386.exp: Run tests for PR ld/18900. * ld-x86-64/x86-64.exp: Likewise. * ld-i386/pr18900.out: New file. * ld-i386/pr18900a.c: Likewise. * ld-i386/pr18900a.c: Likewise. * ld-i386/pr18900a.rd: Likewise. * ld-i386/pr18900b.c: Likewise. * ld-i386/pr18900b.rd: Likewise. * ld-i386/pr18900c.c: Likewise. * ld-x86-64/pr18900.out: Likewise. * ld-x86-64/pr18900a.c: Likewise. * ld-x86-64/pr18900a.rd: Likewise. * ld-x86-64/pr18900b.c: Likewise. * ld-x86-64/pr18900b.rd: Likewise. * ld-x86-64/pr18900c.c: Likewise. * ld-x86-64/mpx3.dd: Updated. -- 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/18900] Unnecessary PLT entry for function pointer initialization
https://sourceware.org/bugzilla/show_bug.cgi?id=18900 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |2.26 --- Comment #2 from H.J. Lu --- Fixed. -- 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/18581] (ARM): issue with function names with a dash inside
https://sourceware.org/bugzilla/show_bug.cgi?id=18581 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #6 from Alan Modra --- Hi Nick, something must have gone wrong with your testsuite runs.. The fixes I made were in response to testsuite regressions. From memory, tilepro didn't build, mn10200, nios2 and fr30 had failing tests. -- 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 binutils/18908] New: how to avoid x86_64-unknown-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=18908 Bug ID: 18908 Summary: how to avoid x86_64-unknown-linux-gnu Product: binutils Version: 2.25 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: linuxcbon at gmail dot com Target Milestone: --- how to reproduce ~ # tar -xvf binutils-2.25.1.tar.bz2 ~ # cd binutils-2.25.1/ ~/binutils-2.25.1 # ./configure --prefix=/usr ~/binutils-2.25.1 # make ~/binutils-2.25.1 # make install it creates a folder /usr/x86_64-unknown-linux-gnu ? I dont want that I want the target I am already using : --target=x86_64-t2-linux-gnu make distclean ./configure --prefix=/usr --target=x86_64-t2-linux-gnu result : ~/binutils-2.25.1 # make make[1]: Entering directory '/root/binutils-2.25.1' Configuring in ./libiberty configure: loading cache ./config.cache configure: error: `target_alias' has changed since the previous run: configure: former value: `x86_64-unknown-linux-gnu' configure: current value: `x86_64-t2-linux-gnu' configure: error: in `/root/binutils-2.25.1/libiberty': configure: error: changes in the environment can compromise the build configure: error: run `make distclean' and/or `rm ./config.cache' and start over Makefile:7990: recipe for target 'configure-libiberty' failed make[1]: *** [configure-libiberty] Error 1 make[1]: Leaving directory '/root/binutils-2.25.1' Makefile:832: recipe for target 'all' failed make: *** [all] Error 2 I already did a "make distclean" and it doesnt work... -- 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/13521] ld.gold prefers unversioned symbol over default version
https://sourceware.org/bugzilla/show_bug.cgi?id=13521
Jason Gunthorpe changed:
What|Removed |Added
CC||jgunthorpe at gmail dot com
--- Comment #5 from Jason Gunthorpe ---
This is still an active problem. I just hit it when working with libsctp on
Ubuntu Vivid:
int main(int argc,const char *argv[])
{
printf("Here %p\n",&sctp_connectx);
}
$ gcc -fuse-ld=gold t.cc -lsctp
$ readelf -s a.out | grep -i sctp
7: 00400520 0 FUNCGLOBAL DEFAULT UND sctp_connectx
36: 0 FUNCGLOBAL DEFAULT UND sctp_connectx
$ gcc t.cc -lsctp
$ readelf -s a.out | grep -i sctp
7: 00400560 0 FUNCGLOBAL DEFAULT UND sctp_connectx@VERS_3
(3)
56: 00400560 0 FUNCGLOBAL DEFAULT UND
sctp_connectx@@VERS_3
The net result is the worst possible scenario - no error, no warning, and the
binary subtly doesn't work because it links to the wrong symbol.
Just like fuse and liblzma5, the author exactly followed the ld documentation
and expected this stuff to work.
I'm not sure why the behaviour of lds.so is being linked to this bug. It is a
good point that a shared library should not depend on this behaviour because it
does not work as described in ld.so. This will impact any transition plan to
introduce the symbol version. It is reasonable for gold to fail to link such
shared libraries.
However that has *NOTHING* to do with linking a new executable against a
library that uses that construct. GNU ld is not broken in this area and the
expected link result is crystal clear - gold should choose the default symbol
marked with @@, not the un-versioned one.
I have no idea how many fringe libraries are out there that followed the GNU
documentation and thus can't be linked into a executable when gold is the
linker. I think it is probably a good enough number that this warrants being
addressed in gold.
--
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/13521] ld.gold prefers unversioned symbol over default version
https://sourceware.org/bugzilla/show_bug.cgi?id=13521 Cary Coutant changed: What|Removed |Added Depends on||18703 Assignee|ian at airs dot com|ccoutant at gmail dot com --- Comment #6 from Cary Coutant --- Have you tried this with a gold built from HEAD? I think that the patches for PR 18703 also fix this bug. Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=18703 [Bug 18703] Symbol version and Version script incompatibility with BFD ld -- 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/18703] Symbol version and Version script incompatibility with BFD ld
https://sourceware.org/bugzilla/show_bug.cgi?id=18703 Cary Coutant changed: What|Removed |Added Blocks||13521 Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=13521 [Bug 13521] ld.gold prefers unversioned symbol over default version -- 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/18703] Symbol version and Version script incompatibility with BFD ld
https://sourceware.org/bugzilla/show_bug.cgi?id=18703 Cary Coutant changed: What|Removed |Added Blocks||12261 Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=12261 [Bug 12261] gold fails to link symbols explicitly defined in base-version -- 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/12261] gold fails to link symbols explicitly defined in base-version
https://sourceware.org/bugzilla/show_bug.cgi?id=12261 Cary Coutant changed: What|Removed |Added Status|NEW |WAITING CC||ccoutant at gmail dot com Depends on||18703 Assignee|ian at airs dot com|ccoutant at gmail dot com --- Comment #10 from Cary Coutant --- Fixed by PR 18703. Gold will accept the base version definition, but the issue Ian raised with glibc is still open. Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=18703 [Bug 18703] Symbol version and Version script incompatibility with BFD ld -- 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/18886] Unnecessary PLT entry for IFUNC function from DSO
https://sourceware.org/bugzilla/show_bug.cgi?id=18886 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ccoutant at gmail dot com |hjl.tools at gmail 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
