[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 fr

[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

[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: --

[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

[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 ti

[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 fres

[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 d

[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: ---

[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 objc

[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 addre

[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 Sev

[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/bugz

[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 f

[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:

[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: gol

[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://sourcew