[Bug ld/10433] Latest ld fails to link ldconfig properly
--- Additional Comments From hjl dot tools at gmail dot com 2009-07-30 16:50 --- If all relocations against an IFUNC symbol are in the same file where it is defined, the ref_regular field may not be set. I changed the x86 linker to set it properly for IFUNC symbols. We need to do it. Otherwise we will run into this bug. If not all backends need it, we can change elflink.c from if ((h-type == STT_GNU_IFUNC h-def_regular !finfo-info-relocatable) to if ((h-type == STT_GNU_IFUNC !finfo-info-relocatable bed-need_finish_dynamic_ifunc_symbol (h)) It will be default to h-def_regular. I can provide a patch if it is OK. -- What|Removed |Added Status|SUSPENDED |NEW http://sourceware.org/bugzilla/show_bug.cgi?id=10433 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10433] Latest ld fails to link ldconfig properly
--- Additional Comments From amodra at bigpond dot net dot au 2009-07-31 01:03 --- bed-need_finish_dynamic_ifunc_symbol is unacceptable in my opinion. Comment #3 says the only difference between good and bad binaries was a .rela.plt relocation. That would seem to indicate that the relocation is being written once with the good symbol, then overwritten with the bad one, when, as you claim, elf_backend_finish_dynamic_symbol is being called unexpectedly. But that means you must have other bugs, since the bad symbol must have plt.offset != -1, which indicates it has a plt entry at the same location as the good symbol! I think you are just papering over real bugs by wanting changes to the set of symbols for which elf_backend_finish_dynamic_symbol is called. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10433 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10433] Latest ld fails to link ldconfig properly
--- Additional Comments From hjl dot tools at gmail dot com 2009-07-31 02:50 --- (In reply to comment #20) Comment #3 says the only difference between good and bad binaries was a .rela.plt relocation. That would seem to indicate that the relocation is being written once with the good symbol, then overwritten with the bad one, when, as you claim, elf_backend_finish_dynamic_symbol is being called unexpectedly. But that means you must have other bugs, since the bad symbol must have plt.offset != -1, which indicates it has a plt entry at the same location as the good symbol! This patch: Index: elf-ifunc.c === --- elf-ifunc.c (revision 6507) +++ elf-ifunc.c (working copy) @@ -193,6 +193,7 @@ _bfd_elf_allocate_ifunc_dyn_relocs (stru || h-got.refcount 0) abort (); h-got.offset = (bfd_vma) -1; + h-plt.offset = (bfd_vma) -1; *head = NULL; return TRUE; } seems to work. I will test it with glibc build. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10433 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10468] New: Problems with GCC Multilib
Please read this bug report I submitted to GCC: One day, I built gcc 4.4.1 prerelease, with normal multilib. The next day, I realized I forgot to add Ada, and all of a sudden multilib failed with the exact same configuration. At the time, I didn't think too much of it and don't remember if anything else happened between the two builds, but it is likely I updated Binutils between those two exact same builds. I have not been getting it to work at all anymore, and I thought it was unique to Cygwin where I couldn't get 4.4.x Multilib for as far as I can remember. I went back to the build that was building in Multilib, and it died with no rule to make 32/zlib. GCC will accept the -m32 flag, but the 64-bit assembler is used. The 32 dir multi-versions are not created, as if multilib was disabled. This is highly likely related to Binutils. However, whether it is a bug in Binutils, or a change in Binutils that caused a bug in 4.4.x to surface, I do not know. I will give you configuration lines (just one time), but believe me, they are not relevant. --enable-multilib wasn't even necessary for gcc, only Binutils. The working multilib version of 4.4.1 I have proves it (via -v.) This bug applies 100% to Linux x86_64 as it does to Windows x64. It has nothing to do with the Mingw-w64 crt, as it occurs before fresh installation of crt, by gcc in make all-gcc (after doing that, building a new crt reveals the incorrect 64-bit assembler.) Binutils (last tried yesterday's update): ../configure --target=x86_64-w64- mingw32 --enable-multilib --enable-targets=x86_64-w64-mingw32,i686-w64- mingw32 --with-sysroot=/mingw64 --prefix=/mingw64 --with-ppl=/usr --with- cloog=/usr GCC 4.4.1 Release: (small testcase) ../configure --target=x86_64-w64-mingw32 --enable-targets=all --with- sysroot=/mingw64 --prefix=/mingw64 --with-ppl=/usr --with-cloog=/usr --enable- languages=c,c++ Thanks, I will pass this same report to Binutils. I could try an older version of Binutils, but I found on Cygwin, the libbfd and/or libopcodes and/or libiberty causes it to fail anyway. I could try in Linux from scratch, again, with an appropriate version (2.19.1?). Please guide me. -- Summary: Problems with GCC Multilib Product: binutils Version: 2.20 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassigned at sources dot redhat dot com ReportedBy: xenofears at gmail dot com CC: bug-binutils at gnu dot org GCC build triplet: x86_64-unknown-linux-gnu, x86_64-w64-mingw32,i686-pc- cygwin, pro GCC host triplet: x86_64-unknown-linux-gnu, x86_64-w64-mingw32,i686-pc- cygwin, pro GCC target triplet: x86_64-w64-mingw32 http://sourceware.org/bugzilla/show_bug.cgi?id=10468 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10468] Problems with GCC Multilib
--- Additional Comments From xenofears at gmail dot com 2009-07-31 03:45 --- Well, trying an old version doesn't really answer the question, it could still be in gcc's field or binutils causing a bug in gcc to surface. I would very much appreciate if Binutils could release numbered snapshot versions/HEAD, but I assume that is a cvs issue. This bug goes back in HEAD/snapshots for I would say a good 2 weeks. Thanks for your attention. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10468 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
