Created attachment 453679 [details] testcase We are unable to build xulrunner with -gstabs+ cxxflag by gcc-4.5.1 under x86_64 arch only. Version-Release number of selected component (if applicable): gcc-4.5.1-3.fc14.x86_64, xulrunner-1.9.2.9 How reproducible: Compile testcase by command: c++ -c -gstabs+ output.cpp Actual results: /tmp/cc19315X.s: Assembler messages: /tmp/cc19315X.s:562: Error: junk at end of line, first unrecognized character is `4' /tmp/cc19315X.s:562: Error: junk at end of line, first unrecognized character is `:' /tmp/cc19315X.s:562: Error: junk at end of line, first unrecognized character is `2' /tmp/cc19315X.s:562: Error: junk at end of line, first unrecognized character is `"'
Why are you trying to build xulrunner with -gstabs+? STABS is an horribly unexpressible old debugging format, which is further completely unsuitable for most of the 64-bit architectures.
Because we need to submit firefox/xulrunner crashes directly at mozilla.org instead of our bugzilla/abrt combo and they require the STABS debuginfo format.
BTW. The same package builds fine in Fedora 13....
Can't reproduce this, neither with 4.5.1-3.fc14 (why are you still using it, it is known to miscompile things) nor 4.5.1-4.fc14, at least not on f13 with the f14 cc1plus. Can you g++ -S -gstabs+ output.ii and as output.s separately and post here how line 562 looks like?
Created attachment 453694 [details] output.s Same problem with gcc-4.5.1-4.fc14.x86_64. Attaching output.s (line 562 is too long to paste here).
Can't reproduce this (with gcc-c++-4.5.1-4.fc14.x86_64 binutils-2.20.51.0.7-5.fc14.x86_64 in mock), neither from the *.ii file, nor with the output.s file.
Still can reproduce with gcc-4.5.1-4.fc14.x86_64 binutils-2.20.51.0.7-5.fc14.x86_64 by: g++ -c output.cpp -gstabs+ /tmp/ccN0IeZP.s: Assembler messages: /tmp/ccN0IeZP.s:562: Error: junk at end of line, first unrecognized character is `4' /tmp/ccN0IeZP.s:562: Error: junk at end of line, first unrecognized character is `:' /tmp/ccN0IeZP.s:562: Error: junk at end of line, first unrecognized character is `2' /tmp/ccN0IeZP.s:562: Error: junk at end of line, first unrecognized character is `"' on kernel 2.6.35.4-28.fc14.x86_64. However cannot reproduce by: as output.s -gstabs+ Scratch build which is failing: http://koji.fedoraproject.org/koji/taskinfo?taskID=2548101
Actually I cannot reproduce it here ... testcase from comment 0 recompiles here just fine with gcc-c++-4.5.1-4.fc14.x86_64 on plain Fedora 14. Could you please post somewhere src.rpm so I can try to reproduce exactly what you are doing? Thank you
Seems to be a bug in gas. $ as -o /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa nsHtml5ElementName.s $ as -o /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa nsHtml5ElementName.s nsHtml5ElementName.s: Assembler messages: nsHtml5ElementName.s:562: Error: junk at end of line, first unrecognized character is `4' nsHtml5ElementName.s:562: Error: junk at end of line, first unrecognized character is `:' nsHtml5ElementName.s:562: Error: junk at end of line, first unrecognized character is `2' nsHtml5ElementName.s:562: Error: junk at end of line, first unrecognized character is `"' $ rpm -qf /usr/bin/as binutils-2.20.51.0.7-5.fc14.x86_64 Once the filename is longer than certain number of bytes, it fails assembling a very long .stabs line (> 9200 chars long line).
Created attachment 460078 [details] nsHtml5ElementName.s Workaround - don't use ccache (then the -o filenames are reasonably short).
Might be a glibc bug too. Matej, if you still have that box around, can you see if glibc-2.12.90-19 helps (and if the box has sse4_2)? I've just spent a lot of time trying to find out why gcc build fails on x86_64 in f15 and it turned about to be buggy glibc on SSE4.2 capable boxes. glibc-2.12.90-19 fixed that.
Ah, the box is still around. So, the answer is easy, the box has sse 4.2, but glibc-2.12.90-19 does not help. Running as under valgrind gives the clues though: valgrind /usr/bin/as -o /tmp/a nsHtml5ElementName.s ==28535== Memcheck, a memory error detector ==28535== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==28535== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==28535== Command: /usr/bin/as -o /tmp/a nsHtml5ElementName.s ==28535== ==28535== Source and destination overlap in memcpy(0x5b3fde1, 0x5b42d2f, 20936) ==28535== at 0x4C27A3A: memcpy (mc_replace_strmem.c:497) ==28535== by 0x411068: input_scrub_next_buffer (string3.h:52) ==28535== by 0x41CC39: read_a_source_file (read.c:612) ==28535== by 0x405808: main (as.c:1044) ==28535== ==28535== ==28535== HEAP SUMMARY: ==28535== in use at exit: 6,985,320 bytes in 8,789 blocks ==28535== total heap usage: 9,717 allocs, 928 frees, 8,737,826 bytes allocated ==28535== ==28535== LEAK SUMMARY: ==28535== definitely lost: 29,810 bytes in 58 blocks ==28535== indirectly lost: 130,400 bytes in 6,520 blocks ==28535== possibly lost: 5,047,136 bytes in 1,389 blocks ==28535== still reachable: 1,777,974 bytes in 822 blocks ==28535== suppressed: 0 bytes in 0 blocks ==28535== Rerun with --leak-check=full to see details of leaked memory ==28535== ==28535== For counts of detected and suppressed errors, rerun with: -v ==28535== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6) And a quick look at the code in question reveals this is http://sourceware.org/bugzilla/show_bug.cgi?id=11456
Hi Guys, I have imported the patch for PR 11456 into the F14 binutils branch: binutils-2.20.51.0.7-6.fc14.x86_64 Can someone let me know if this is sufficient to fix the problem ? Cheers Nick
Looks fine. Cannot reproduce with binutils-2.20.51.0.7-6.fc14.x86_64.
Releasing the box, it doesn't seem like it is needed anymore.
binutils-2.20.51.0.7-6.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/binutils-2.20.51.0.7-6.fc14
binutils-2.20.51.0.7-6.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update binutils'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/binutils-2.20.51.0.7-6.fc14
binutils-2.20.51.0.7-6.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.