I ran across this situation due some .comm symbols being generated by gcc. I don't think it's a gcc problem per se, unless symbols are not allowed to begin with a "." The new underscoring behavior for 64 bit mingw 32 targets can break the linker's expectation for the syntax of the -aligncomm .drectve section. With the new underscoring behavior, gcc generated a symbol that looked like this in the assembly: .comm .gomp_critical_user_critical_foox, 8, 3 Gas translated that into: .drectve -aligncomm:.gomp_critical_user_critical_foox,3 Which generated a linker error: /opt/devtools/x86_64-pc-linux/x86_64-w64-mingw32/bin/ld: <unknown-file>:0: syntax error Warning: .drectve `-aligncomm:.gomp_critical_user_critical_foox,3' unrecognized The 32 bit side worked because gcc generated the symbol with a leading underscore. This is easy to replicate by: echo ".comm .foo 8, 3" | x86_64-w64-mingw32-as - -o test.o && x86_64-w64-mingw32-ld -dll test.o -o test.dll
Hi Doug, I tried to reproduce this problem but could not. Would it be possible for you to upload the test.o file from your example ? Also please could you check to see if the problem still exists with the latest binutils sources. Cheers Nick
I believe this bug is now fixed at v1.33 of depfile.y that Kai checked in yesterday (allow leading . for symbol names in the parser).
I'm reopening this bug: I believe the patch that fixed this in deffilep.y introduced a shift-reduce conflict that now fails to align properly any symbol that is listed in the tokens[] array on or about line 960. The leading . symbols work. For example, if you align a variable named data, BASE, etc, a -aligncomm directive will be emitted in the object: echo ".comm data 8, 3" | x86_64-w64-mingw32-as - -o test.o && x86_64-w64-mingw32-ld -dll test.o -o test.dll x86_64-w64-mingw32-ld: <unknown-file>:0: syntax error Warning: .drectve `-aligncomm:data,3' unrecognized (Note, this was discovered during gcc testsuite)
The failure isn't reasoned by shift reduces. The underlying problem you see here is, that for IDs the keywords aren't recognized. So symbols named 'data', or 'BASE', etc aren't recognized by grammer. This behavior can't happen for targets with leading underscore symbols (obviously). So I assume that the same issue is present for arm-pe targets, as those have no-leading underscore, too. Fix posted to binutils ML. Regards, Kai
The solution for this issue is to quote the name by '. This prevents that the .def file parser treats the symbol name as keyword.
Subject: Bug 11612 CVSROOT: /cvs/src Module name: src Changes by: ktietz@sourceware.org 2010-07-11 08:45:51 Modified files: gas : ChangeLog gas/config : obj-coff.c gas/testsuite : ChangeLog gas/testsuite/gas/i386: i386.exp gas/testsuite/gas/pe: aligncomm-b.d aligncomm-d.d Log message: 2010-07-11 Kai Tietz <kai.tietz@onevision.com> PR ld/11612 * config/obj-coff.c (obj_common_parse): Quote symbol-name. 2010-07-11 Kai Tietz <kai.tietz@onevision.com> * gas/pe/aligncomm-b.d: Regenerated content dump. * gas/pe/aligncomm-d,d: Regenerated content dump. * gas/i386/i386.exp: Disable for mingw 64-bit the intel-got64 test. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/ChangeLog.diff?cvsroot=src&r1=1.4196&r2=1.4197 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/config/obj-coff.c.diff?cvsroot=src&r1=1.105&r2=1.106 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/testsuite/ChangeLog.diff?cvsroot=src&r1=1.1699&r2=1.1700 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/i386/i386.exp.diff?cvsroot=src&r1=1.140&r2=1.141 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/pe/aligncomm-b.d.diff?cvsroot=src&r1=1.1&r2=1.2 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/pe/aligncomm-d.d.diff?cvsroot=src&r1=1.1&r2=1.2
This bug was fixed by recent patch.