Windows XP/SP2 cygwin on pentium4 single i686: binutils 20050520-1 OK bison 20030307-1 OK cygwin 1.5.17-1 OK dejagnu 20021217-2 OK expect 20030128-1 OK gcc 3.3.3-3 OK make 3.80-1 OK tcltk 20030901-1 OK LAST_UPDATED: Sun May 29 10:40:29 UTC 2005 Native configuration is i686-pc-cygwin Running /usr/local/src/trunk/src/ld/testsuite/ld-scripts/weak.exp ... /usr/local/src/trunk/objdir-binutils32/ld/../gas/as-new -o tmpdir/weak1.o /usr/local/src/trunk/src/ld/testsuite/ld-scripts/weak1.s /usr/local/src/trunk/objdir-binutils32/ld/../gas/as-new -o tmpdir/weak2.o /usr/local/src/trunk/src/ld/testsuite/ld-scripts/weak2.s /usr/local/src/trunk/objdir-binutils32/ld/ld-new -o tmpdir/weak --image-base 0 -T /usr/local/src/trunk/src/ld/testsuite/ld-scripts/weak.t tmpdir/weak1.o tmpdir/weak2.o /usr/local/src/trunk/objdir-binutils32/ld/../binutils/objdump -s tmpdir/weak tmpdir/weak: file format pei-i386 Contents of section .text: 1000 08100000 18200000 12121212 34343434 ..... ......4444 Contents of section .data: 2000 10100000 0c200000 56565656 78787878 ..... ..VVVVxxxx FAIL: weak symbols testcase /usr/local/src/trunk/src/ld/testsuite/ld-scripts/weak.exp completed in 0 seconds
ping... still there: Running /usr/local/src/trunk/src/ld/testsuite/ld-scripts/weak.exp ... /usr/local/src/trunk/objdir-binutils/ld/../gas/as-new -o tmpdir/weak1.o /usr/local/src/trunk/src/ld/testsuite/ld-scripts/weak1.s /usr/local/src/trunk/objdir-binutils/ld/../gas/as-new -o tmpdir/weak2.o /usr/local/src/trunk/src/ld/testsuite/ld-scripts/weak2.s /usr/local/src/trunk/objdir-binutils/ld/ld-new -o tmpdir/weak --image-base 0 -T /usr/local/src/trunk/src/ld/testsuite/ld-scripts/weak.t tmpdir/weak1.o tmpdir/weak2.o /usr/local/src/trunk/objdir-binutils/ld/../binutils/objdump -s tmpdir/weak tmpdir/weak: file format pei-i386 Contents of section .text: 1000 08100000 18200000 12121212 34343434 ..... ......4444 Contents of section .data: 2000 10100000 0c200000 56565656 78787878 ..... ..VVVVxxxx FAIL: weak symbols testcase /usr/local/src/trunk/src/ld/testsuite/ld-scripts/weak.exp completed in 2 seconds This is with Windows XP Pro/SP2 cygwin Pentium M processor 2.13GHz system with packages: binutils 20050610-1 2.16.91 20050610 bison 2.1-1 2.1 cygwin 1.5.19-4 dejagnu 20021217-2 1.4.2.x expect 20030128-1 5.26 gcc 3.4.4-1 gmp 4.1.4-2 make 3.80-1 OK tcltk 20030901-1 8.4 LAST_UPDATED: Wed May 3 16:45:38 UTC 2006 Native configuration is i686-pc-cygwin
still there... as of 2006-06-24
Blimey! Hello Christian, I've just been catching up on the various Cygwin binutils failures and reached this one. Detailed analysis going on now in the thread on the binutils list at http://sourceware.org/ml/binutils/2009-03/threads.html#00314 and more to come.
This bug may be related the the already fixed Bug #3041 about weak symbols on a.out targets.
(In reply to comment #4) > This bug may be related the the already fixed Bug #3041 about weak symbols on > a.out targets. Ah, thanks for the pointer! It looks like we're ok on point #1 (the reloc against a weak symbol being converted to an offset from the section base symbol, that's not happening on x86/PE) and I'm half-way through recreating your patch #3 (In md_apply_fix(): Always put zero values into frags referencing a weak symbol). >There is still a bug when the reference to the weak symbol contains an offset. >With my previous patch, the offset is unconditionnaly set to 0. Heh, you ran up into the problem that I am anticipating finding next! Thanks a lot Vincent, you seem to have discovered and solved the exact same problem on m68k and your patches will be very useful for me :)
Still there, I guess: testcase /usr/local/src/trunk/src/ld/testsuite/ld-scripts/sizeof.exp completed in 3 seconds Running /usr/local/src/trunk/src/ld/testsuite/ld-scripts/sort.exp ... testcase /usr/local/src/trunk/src/ld/testsuite/ld-scripts/sort.exp completed in 0 seconds Running /usr/local/src/trunk/src/ld/testsuite/ld-scripts/weak.exp ... /usr/local/src/trunk/objdir-binutils/ld/../gas/as-new -o tmpdir/weak1.o /usr/local/src/trunk/src/ld/testsuite/ld-scripts/weak1.s Executing on host: sh -c {/usr/local/src/trunk/objdir-binutils/ld/../gas/as- new -o tmpdir/weak1.o /usr/local/src/trunk/src/ld/testsuite/ld- scripts/weak1.s 2>&1} /dev/null ld.tmp (timeout = 300) spawn [open ...] /usr/local/src/trunk/objdir-binutils/ld/../gas/as-new -o tmpdir/weak2.o /usr/local/src/trunk/src/ld/testsuite/ld-scripts/weak2.s Executing on host: sh -c {/usr/local/src/trunk/objdir-binutils/ld/../gas/as- new -o tmpdir/weak2.o /usr/local/src/trunk/src/ld/testsuite/ld- scripts/weak2.s 2>&1} /dev/null ld.tmp (timeout = 300) spawn [open ...] /usr/local/src/trunk/objdir-binutils/ld/ld-new -o tmpdir/weak --image-base 0 - T /usr/local/src/trunk/src/ld/testsuite/ld-scripts/weak.t tmpdir/weak1.o tmpdir/weak2.o Executing on host: sh -c {/usr/local/src/trunk/objdir-binutils/ld/ld-new -o tmpdir/weak --image-base 0 -T /usr/local/src/trunk/src/ld/testsuite/ld- scripts/weak.t tmpdir/weak1.o tmpdir/weak2.o 2>&1} /dev/null ld.tmp (timeout = 300) spawn [open ...] /usr/local/src/trunk/objdir-binutils/ld/../binutils/objdump -s tmpdir/weak Executing on host: sh -c {/usr/local/src/trunk/objdir- binutils/ld/../binutils/objdump -s tmpdir/weak 2>&1} /dev/null ld.tmp (timeout = 300) spawn [open ...] tmpdir/weak: file format pei-i386 Contents of section .text: 1000 08100000 18200000 12121212 34343434 ..... ......4444 Contents of section .data: 2000 10100000 0c200000 56565656 78787878 ..... ..VVVVxxxx tmpdir/weak: file format pei-i386 Contents of section .text: 1000 08100000 18200000 12121212 34343434 ..... ......4444 Contents of section .data: 2000 10100000 0c200000 56565656 78787878 ..... ..VVVVxxxx tmpdir/weak: file format pei-i386 Contents of section .text: 1000 08100000 18200000 12121212 34343434 ..... ......4444 Contents of section .data: 2000 10100000 0c200000 56565656 78787878 ..... ..VVVVxxxx FAIL: weak symbols testcase /usr/local/src/trunk/src/ld/testsuite/ld-scripts/weak.exp completed in 4 seconds This was on Windows XP Pro/SP3 cygwin Pentium M processor 2.13GHz system with packages: binutils 20080624-2 2.18.50.20080625 bison 2.3-1 2.3 cygwin 1.5.25-15 dejagnu 20021217-2 1.4.2.x expect 20030128-1 5.26 gcc-ada 3.4.4-999 gcc-core 3.4.4-999 gcc-g++ 3.4.4-999 gmp 4.2.4-1 libgmp-devel 4.2.4-1 libmpfr-devel 2.4.1-1 make 3.81-2 mpfr 2.4.1-1 tcltk 20080420-1 8.4 w32api 3.13-1 LAST_UPDATED: daily snapshot 2009-03-23: 2.19.51.20090323
(In reply to comment #6) > Still there, I guess: Yep, there was a big thread about it at http://sourceware.org/ml/binutils/2009-03/threads.html#00314 I'm drawing up a plan to support ELF-style weaks without breaking mingw-msvc linkage.
I notice a few checkins that I suspect might be related to eventually resolve this PR... Dave, what is the status on this work?
Crude proto-patch unsuitable for submission posted at http://sourceware.org/ml/binutils/2009-04/msg00133.html along with rationale for a design that implements non-MS-compatible C_WEAKEXT symbols. Dropped it on the floor a little since then to look at libgcj dll problems, want to get back to it soon. (Have been having second thoughts about whether I might just be able to make it work with compatible C_NT_WEAK symbols after all). Sorry for the lack of movement, there'll be more soon.
Created attachment 3962 [details] Testcases, object files generated with vendor tools, patch. I have been analysing how the vendor tools work in order to verify our weak externals implementation against MS' tools behaviour. Here are some tests and specimen object files; I will enter some analysis of what I have found out in comments in the PR shortly. See README.txt for description of archive contents.
Created attachment 3963 [details] Examination of absolute (non-pc-relative) relocs against weak syms in MS and GNU At 16kB, this detailed examination is probably a bit long to post in a comment, so I am attaching it. The executive summary: ----------------------------------------------------------------------------- My conclusion from this is that GAS' behaviour is currently incorrect w.r.t the generation of MS-style weak externals, and should be adapted to match the behaviour of MASM. This change alone will resolve the testcase and PR977, and by all appearances should be more correct and interoperable than the current situation. ----------------------------------------------------------------------------- and to prove it I've made the assembler and linker match what the MS tools do: ----------------------------------------------------------------------------- MS tools: Contents of section .data: 401000 28104000 0c104000 56565656 78787878 (.@...@.VVVVxxxx 401010 2b1d4000 0d1c4000 35134000 0d1f4000 +.@...@.5.@...@. 401020 28104000 0c104000 12121212 34343434 (.@...@.....4444 401030 35134000 0d1f4000 2b1d4000 0d1c4000 5.@...@.+.@...@. Unpatched binutils: Contents of section .text: 401000 30104000 0c104000 56565656 78787878 0.@...@.VVVVxxxx ^^ 401010 331d4000 0d1c4000 3d134000 0d1f4000 3.@...@.=.@...@. ^^ ^^ 401020 28104000 18104000 12121212 34343434 (.@...@.....4444 ^^ 401030 35134000 191f4000 2b1d4000 191c4000 5.@...@.+.@...@. ^^ ^^ With the patch included in the previous attachment (examples.tar.bz2): Contents of section .text: 401000 28104000 0c104000 56565656 78787878 (.@...@.VVVVxxxx 401010 2b1d4000 0d1c4000 35134000 0d1f4000 +.@...@.5.@...@. 401020 28104000 0c104000 12121212 34343434 (.@...@.....4444 401030 35134000 0d1f4000 2b1d4000 0d1c4000 5.@...@.+.@...@. ----------------------------------------------------------------------------- Full details inside. More to follow re: pc-relative relocs.
Created attachment 3973 [details] More testcases, object files generated with vendor tools, patch.
Created attachment 3974 [details] Examination of pc-relative relocs against weak syms in MS and GNU Again, it turns out we need to clear the inplace reloc field to generate correct and interoperable object files to work with MS tools. Once we do that, we can get byte-for-byte identical final linked executables: ----------------------------------------------------- $ objdump -s j34.patched.x j34.ms.x j34.patched.x: file format pei-i386 Contents of section .text: 401000 e9360000 00ff250f 10400056 56565678 .6....%..@.VVVVx 401010 787878e9 260d0000 ff25101c 4000e925 xxx.&....%..@..% 401020 030000ff 25101f40 00000000 00000000 ....%..@........ 401030 ff253b10 4000e9d4 ffffff12 12121234 .%;.@..........4 401040 343434ff 25481340 00e9c20e 0000ff25 444.%H.@.......% 401050 3e1d4000 e9b70b00 00000000 00000000 >.@............. j34.ms.x: file format pei-i386 Contents of section .data: 401000 e9360000 00ff250f 10400056 56565678 .6....%..@.VVVVx 401010 787878e9 260d0000 ff25101c 4000e925 xxx.&....%..@..% 401020 030000ff 25101f40 00000000 00000000 ....%..@........ 401030 ff253b10 4000e9d4 ffffff12 12121234 .%;.@..........4 401040 343434ff 25481340 00e9c20e 0000ff25 444.%H.@.......% 401050 3e1d4000 e9b70b00 00 >.@...... ----------------------------------------------------- So, I think I know what we need to do now, and a patch to the list will follow.
Subject: Bug 977 CVSROOT: /cvs/src Module name: src Changes by: davek@sourceware.org 2009-06-08 16:06:24 Modified files: gas/config : tc-i386.c gas : ChangeLog Log message: PR gas/977 * config/tc-i386.c (md_estimate_size_before_relax): Don't relax branches to weak symbols. (md_apply_fix): Don't convert fixes against weak symbols to section-relative offsets, but save addend for later reloc emission. (tc_gen_reloc): When emitting reloc against weak symbol, adjust addend to pre-compensate for bfd_install_relocation. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/config/tc-i386.c.diff?cvsroot=src&r1=1.375&r2=1.376 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/ChangeLog.diff?cvsroot=src&r1=1.3820&r2=1.3821
:-) Christian, please verify. (Well, you have already I guess!)
Confirmed to resolve test suite failure. See http://sourceware.org/ml/binutils/2009-06/msg00148.html
bah, wrong test suite run above... I used my local variant with Korn's patch already in, this time, I used the pure cvs checkout. See http://sourceware.org/ml/binutils/2009-06/msg00149.html
Technically the bug reporter should be the one to set the "verified" flag, but you clearly confirmed it was verified, so I'll do it. Thanks for testing!