[Bug ld/15444] Use of -g for large project results in: relocation truncated to fit: R_X86_64_32 against `.debug_info'
http://sourceware.org/bugzilla/show_bug.cgi?id=15444 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #2 from H.J. Lu 2013-05-08 17:47:21 UTC --- Your debug info sections are too big. You need to reduce sizes of debug info sections in a single shared library. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15444] Use of -g for large project results in: relocation truncated to fit: R_X86_64_32 against `.debug_info'
http://sourceware.org/bugzilla/show_bug.cgi?id=15444 --- Comment #3 from Peeter Joot 2013-05-08 17:58:57 UTC --- Is there a mechanism to do this? -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15444] Use of -g for large project results in: relocation truncated to fit: R_X86_64_32 against `.debug_info'
http://sourceware.org/bugzilla/show_bug.cgi?id=15444 --- Comment #4 from H.J. Lu 2013-05-08 18:35:33 UTC --- You can avoid -g or break one big shared library into 2. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15444] Use of -g for large project results in: relocation truncated to fit: R_X86_64_32 against `.debug_info'
http://sourceware.org/bugzilla/show_bug.cgi?id=15444 Paul Pluzhnikov changed: What|Removed |Added CC||ppluzhnikov at google dot ||com --- Comment #5 from Paul Pluzhnikov 2013-05-08 18:47:13 UTC --- (In reply to comment #4) > You can avoid -g or break one big shared library into 2. Neither of these approaches is particularly appealing (the tail is wagging the dog here). Peeter may be interested in the fission work: http://gcc.gnu.org/ml/gcc/2011-10/msg00326.html http://gcc.gnu.org/wiki/DebugFission -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15444] Use of -g for large project results in: relocation truncated to fit: R_X86_64_32 against `.debug_info'
http://sourceware.org/bugzilla/show_bug.cgi?id=15444 --- Comment #6 from Peeter Joot 2013-05-08 19:00:01 UTC --- Looks like the fission work is a plan to take --build-id or debug-link separation of the binary and debug info to the next logical step, separating it into a different file at link time. I was looking for such a mechanism when I asked the following: http://stackoverflow.com/questions/16408893/gnu-ld-gdb-separate-debug-files-how-to-produce-the-debug-file-when-theres-too What's the state of this work? -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15444] Use of -g for large project results in: relocation truncated to fit: R_X86_64_32 against `.debug_info'
http://sourceware.org/bugzilla/show_bug.cgi?id=15444 --- Comment #7 from Paul Pluzhnikov 2013-05-08 19:07:41 UTC --- (In reply to comment #6) > What's the state of this work? It is committed in GCC-4.8, trunk binutils/gold, and GDB 7.6. We are starting to use it at Google, but it is very fresh, and we are discovering some bugs in both gold and GDB. If you can wait another 3 months, fission will likely become more stable. Or join the party as an early adopter :-) -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15444] Use of -g for large project results in: relocation truncated to fit: R_X86_64_32 against `.debug_info'
http://sourceware.org/bugzilla/show_bug.cgi?id=15444 --- Comment #8 from Peeter Joot 2013-05-08 22:19:26 UTC --- Note that as well as having the (very interesting) fission support, the gold linker is able to link the same large shared lib that the bfd linker bombs attempting (also allowing the debug symbols to be stripped out into a separate file even without the fission support using the --build-id or --add-gnu-debuglink mechanisms for external debug info). -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15444] Use of -g for large project results in: relocation truncated to fit: R_X86_64_32 against `.debug_info'
http://sourceware.org/bugzilla/show_bug.cgi?id=15444 --- Comment #9 from H.J. Lu 2013-05-09 00:02:05 UTC --- Do you have a testcase? Which version of ICC are you using? -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15444] Use of -g for large project results in: relocation truncated to fit: R_X86_64_32 against `.debug_info'
http://sourceware.org/bugzilla/show_bug.cgi?id=15444 --- Comment #10 from Peeter Joot 2013-05-09 00:52:43 UTC --- I'm using: icpc (ICC) 13.0.0 20130327 I could potentially bundle up all the required .a's and other auxillary libraries required to reproduce this... but it would be huge (my objcopy --only-keep-debug output alone is about 6Gb). -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15444] Use of -g for large project results in: relocation truncated to fit: R_X86_64_32 against `.debug_info'
http://sourceware.org/bugzilla/show_bug.cgi?id=15444 --- Comment #11 from Alan Modra 2013-05-09 01:31:52 UTC --- Peeter, the answer to your original question is (3). This is a limitation of the debug format variant that was used when compiling crtn.o. DWARF allows different encodings for addresses and offsets. In your case you have a 32-bit offset being used in .debug_aranges to access something in .debug_info, which apparently is too large for a 32-bit offset. Stripping the debug info out of crtn.o might work for you. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15447] New: dwp crashes with fseek(NULL) when executable without any .dwo files is specified
http://sourceware.org/bugzilla/show_bug.cgi?id=15447 Bug #: 15447 Summary: dwp crashes with fseek(NULL) when executable without any .dwo files is specified Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gold AssignedTo: i...@airs.com ReportedBy: ppluzhni...@google.com CC: ccout...@google.com Classification: Unclassified Reported by Peeter Joot: dwp built from current trunk: gdb -q --args gold/dwp -o t --exec /bin/date Reading symbols from /build/gold/dwp...done. (gdb) r Starting program: /build/gold/dwp -o t --exec /bin/date Program received signal SIGSEGV, Segmentation fault. __GI_fseek (fp=0x0, offset=0, whence=0) at fseek.c:40 40 fseek.c: No such file or directory. (gdb) bt #0 __GI_fseek (fp=0x0, offset=0, whence=0) at fseek.c:40 #1 0x00407841 in gold::Dwp_output_file::write_new_section (this=0x7fffcfe0, section_name=0x5f3508 ".debug_cu_index", contents=0x8d0710 "\002", len=16, align=8) at ../../src/gold/dwp.cc:1812 #2 0x0041f74d in gold::Dwp_output_file::write_index (this=0x7fffcfe0, sect_name=0x5f3508 ".debug_cu_index", index=...) at ../../src/gold/dwp.cc:1921 #3 0x00407be5 in gold::Dwp_output_file::finalize (this=0x7fffcfe0) at ../../src/gold/dwp.cc:1725 #4 0x00405c02 in main (argc=5, argv=0x7fffd418) at ../../src/gold/dwp.cc:2278 -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15444] Use of -g for large project results in: relocation truncated to fit: R_X86_64_32 against `.debug_info'
http://sourceware.org/bugzilla/show_bug.cgi?id=15444 --- Comment #12 from Peeter Joot 2013-05-09 02:42:10 UTC --- Hi Alan, Interesting, however, if that is the case, what's the reason that I can work around this by switching to the gold linker. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15444] Use of -g for large project results in: relocation truncated to fit: R_X86_64_32 against `.debug_info'
http://sourceware.org/bugzilla/show_bug.cgi?id=15444 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #13 from Alan Modra 2013-05-09 03:02:55 UTC --- Perhaps gold is better at removing duplicate debug info, so the resulting .debug_info is smaller? Or perhaps gold places debug sections in a different order, resulting in the relative offset from the .debug_aranges field to the .debug_info location being smaller? Whatever the reason, I'd wager you will run into trouble even with gold if you make your shared library large enough. Another possibility is that gold is simply not reporting an error on relocation overflow.. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15444] Use of -g for large project results in: relocation truncated to fit: R_X86_64_32 against `.debug_info'
http://sourceware.org/bugzilla/show_bug.cgi?id=15444 --- Comment #14 from Alan Modra 2013-05-09 04:23:53 UTC --- Yes, gold is "succeeding" simply because it doesn't report the overflow. :-( case elfcpp::R_X86_64_32: // FIXME: we need to verify that value + addend fits into 32 bits: -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15449] New: internal error in set_offset, at output.cc:4665
http://sourceware.org/bugzilla/show_bug.cgi?id=15449 Bug #: 15449 Summary: internal error in set_offset, at output.cc:4665 Product: binutils Version: 2.23 Status: NEW Severity: normal Priority: P2 Component: gold AssignedTo: i...@airs.com ReportedBy: ar...@maven.pl CC: ccout...@google.com Classification: Unclassified Created attachment 7018 --> http://sourceware.org/bugzilla/attachment.cgi?id=7018 how to reproduce $ ld.gold -m elf_i386 -static -o aaa -z relro sb.o libuuid.a ld.gold: internal error in set_offset, at output.cc:4665 The problem happens on i686 and i686. Doesn't happen on x86_64 $ ld.gold --version GNU gold (Linux/GNU Binutils 2.23.52.0.2.20130423) 1.11 Copyright 2013 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15449] internal error in set_offset, at output.cc:4665
http://sourceware.org/bugzilla/show_bug.cgi?id=15449 --- Comment #1 from Arkadiusz Miskiewicz 2013-05-09 06:07:16 UTC --- (In reply to comment #0) > The problem happens on i686 and i686. Doesn't happen on x86_64 Happens on i486 and i686. Doesn't on x86_64. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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
