> cat t1.s .text .globl main .type main, @function main: ret .section .debug_info,"",@progbits .long t.c.4903c230+2 > cat t2.s .section .debug_info,"",@progbits .hidden t.c.4903c230 .globl t.c.4903c230 t.c.4903c230: .long 0x28 > as -o t1.o t1.s > as -o t2.o t2.s > ld -o t.o t1.o t2.o --gc-sections --entry=main > readelf -S t.o | grep debug_info [ 2] .debug_info PROGBITS 0000000000000000 00000079 > readelf -x 2 t.o Hex dump of section '.debug_info': 0x00000000 00000000 .... while gold is fine: > gold -o t.o t1.o t2.o --gc-sections --entry=main > readelf -S t.o | grep debug_info [ 2] .debug_info PROGBITS 0000000000000000 00000079 > readelf -x 2 t.o Hex dump of section '.debug_info': 0x00000000 06000000 28000000 ....(...
Reconfirmed with 2.28 and with master. This breaks the debuginfo in the final link when doing early LTO debug objects.
Gold keeps all debug info even if they aren't needed: [hjl@gnu-6 pr20882]$ cat t1.s .text .globl main .type main, @function main: ret .section .debug_info,"",@progbits .long t.c.4903c230+2 [hjl@gnu-6 pr20882]$ cat t2.s .section .debug_info,"",@progbits .hidden t.c.4903c230 .globl t.c.4903c230 t.c.4903c230: .long 0x28 [hjl@gnu-6 pr20882]$ cat t3.s .section .debug_info,"",@progbits .hidden t.c.4903c231 .globl t.c.4903c231 t.c.4903c231: .long 0x29 [hjl@gnu-6 pr20882]$ make y as -o t1.o t1.s as -o t2.o t2.s as -o t3.o t3.s ld.gold --entry=main -o y t1.o t2.o t3.o [hjl@gnu-6 pr20882]$ readelf -x .debug_info y Hex dump of section '.debug_info': 0x00000000 06000000 28000000 29000000 ....(...)... [hjl@gnu-6 pr20882]$
On May 16, 2017 7:17:40 PM GMT+02:00, "hjl.tools at gmail dot com" <sourceware-bugzilla@sourceware.org> wrote: >https://sourceware.org/bugzilla/show_bug.cgi?id=20882 > >--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> --- >Gold keeps all debug info even if they aren't needed: > >[hjl@gnu-6 pr20882]$ cat t1.s > .text > .globl main > .type main, @function >main: > ret > > .section .debug_info,"",@progbits > .long t.c.4903c230+2 >[hjl@gnu-6 pr20882]$ cat t2.s > > .section .debug_info,"",@progbits > .hidden t.c.4903c230 > .globl t.c.4903c230 >t.c.4903c230: > .long 0x28 >[hjl@gnu-6 pr20882]$ cat t3.s > > .section .debug_info,"",@progbits > .hidden t.c.4903c231 > .globl t.c.4903c231 >t.c.4903c231: > .long 0x29 >[hjl@gnu-6 pr20882]$ make y >as -o t1.o t1.s >as -o t2.o t2.s >as -o t3.o t3.s >ld.gold --entry=main -o y t1.o t2.o t3.o >[hjl@gnu-6 pr20882]$ readelf -x .debug_info y > >Hex dump of section '.debug_info': > 0x00000000 06000000 28000000 29000000 ....(...)... > >[hjl@gnu-6 pr20882]$ Probably makes sense. How's debug info made 'necessary' otherwise? I presume GNU ld keeps all debug info from an object that has any other objects used?
Created attachment 10052 [details] Try this
Some targets, like mips, keep input files when there are some special sections, like .gnu.attributes, even if input file is unused otherwise. In this case, all debug sections are kept.
A patch is posted at https://sourceware.org/ml/binutils/2017-05/msg00195.html
The master branch has been updated by H.J. Lu <hjl@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b7c871edcd83ccdc5fcd8148a7f433efd6b52255 commit b7c871edcd83ccdc5fcd8148a7f433efd6b52255 Author: H.J. Lu <hjl.tools@gmail.com> Date: Wed May 17 07:57:15 2017 -0700 Mark debug sections referenced by kept debug sections If a debug section is referenced by a kept debug section, it should also be kept. Some targets, like mips, keep input files when there are some special sections, like .gnu.attributes, even if input file is unused otherwise. In this case, all debug sections are kept. The new test will fail on such targets. We can either fix those targets or XFAIL the test. bfd/ PR ld/20882 * elflink.c (elf_gc_mark_debug_section): New function. (_bfd_elf_gc_mark_extra_sections): Mark any debug sections referenced by kept debug sections. ld/ PR ld/20882 * testsuite/ld-gc/gc.exp: Run pr20882. * testsuite/ld-gc/pr20882.d: New file. * testsuite/ld-gc/pr20882a.s: Likewise. * testsuite/ld-gc/pr20882b.s: Likewise. * testsuite/ld-gc/pr20882c.s: Likewise.
Fixed for 2.29.
The master branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=087ea22225435ab5800e6c29671acab40dc6ca82 commit 087ea22225435ab5800e6c29671acab40dc6ca82 Author: Alan Modra <amodra@gmail.com> Date: Thu May 18 14:28:17 2017 +0930 pr20882 testcase -gdwarf-sections doesn't work on targets that lack support to emit address size relative relocs. The testcase as it was avoided -gdwarf-sections doing anything by providing a non-empty .debug_line. It's better to not use -gdwarf-sections. Also, the testcase failed to match the output for 16-bit address targets like avr. PR ld/20882 * testsuite/ld-gc/pr20882.d: Don't pass -gdwarf-sections to gas. Allow for 16-bit address targets and match expected data fully. * testsuite/ld-gc/pr20882a.s: Delete .debug_line section. * testsuite/ld-gc/pr20882b.s: Likewise. * testsuite/ld-gc/pr20882c.s: Likewise.
On Wed, 17 May 2017, hjl.tools at gmail dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=20882 > > H.J. Lu <hjl.tools at gmail dot com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |RESOLVED > Resolution|--- |FIXED > Target Milestone|--- |2.29 > > --- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> --- > Fixed for 2.29. Thanks HJ!
Hi H.J. Unfortunately your new test fails for a number of targets: FAIL: --gc-sections with relocations in debug section arm-none-eabi xgate-elf mipsisa32el-linux mips-sgi-irix6 crx-elf mipsel-linux-gnu tic6x-elf tx39-elf mips64-linux xtensa-elf armeb-eabi msp430-elf v850-elf mips-elf arm-netbsdelf Please could you have a look and see if you can fix/xfail them ? Cheers Nick
The crx and xgate FAILs are due to broken relocation processing. I don't think they should be swept under the rug. HJ has already pointed out why mips is failing in https://sourceware.org/ml/binutils/2017-05/msg00195.html. I've looked into the arm failure, which is due to .ARM.attributes being marked KEEP and then _bfd_elf_gc_mark_extra_sections setting some_kept. A possible fix is to only set some_kept when an *alloc* section is kept. Testing that now.
We may also keep debug sections in otherwise unused files if there is a .note.gnu.property section.
The issue persists in 2.29.1 at least. Index: libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp =================================================================== --- libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp (revision 258481) +++ libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp (working copy) @@ -50,7 +50,7 @@ gdb-dg-runtest [lsort [glob $srcdir/$sub if { [check_effective_target_lto] } { append cxxflags " -flto" # work around sourceware.org 20882 - regsub {^(.*)-Wl,--gc-sections(.*)$} $cxxldflags {\1\2} cxxldflags + #regsub {^(.*)-Wl,--gc-sections(.*)$} $cxxldflags {\1\2} cxxldflags gdb-dg-runtest [lsort [glob $srcdir/$subdir/*.cc]] \ "" "$DEFAULT_CXXFLAGS -flto $PCH_CXXFLAGS" } shows the issue in a gcc tree with > make check-target-libstdc++-v3 RUNTESTFLAGS="prettyprinters.exp" you then get UNSUPPORTED tests with complaints like spawn gdb -nx -nw -quiet -batch -x cxx11.gdb^M Dwarf Error: could not find abbrev number 151 [in module /tmp/obj/x86_64-pc-linux-gnu/libstdc++-v3/testsuite/cxx11.exe]^M skipping: Dwarf Error: could not find abbrev number 151 [in module /tmp/obj/x86_64-pc-linux-gnu/libstdc++-v3/testsuite/cxx11.exe]^M cxx11.gdb:5: Error in sourced command file:^M No symbol table is loaded. Use the "file" command.^M skipping: cxx11.gdb:5: Error in sourced command file:^M skipping: No symbol table is loaded. Use the "file" command.^M UNSUPPORTED: libstdc++-prettyprinters/cxx11.cc See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847
The original testcase is fixed tho.
(In reply to Richard Biener from comment #15) > The original testcase is fixed tho. For https://github.com/davidmalcolm/rhbz-1543912 with binutils master branch, I got mkdir build gcc -I ./src -flto -O2 -g -c src/bootchart.c -o build/bootchart.o gcc -I ./src -flto -O2 -g -c src/log.c -o build/log.o gcc -flto -g -Wl,--gc-sections -Wl,--print-gc-sections \ build/bootchart.o build/log.o \ -o build/systemd-bootchart /usr/local/bin/ld: removing unused section '.rodata.cst4' in file '/usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/crt1.o' /usr/local/bin/ld: removing unused section '.data' in file '/usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/crt1.o' /usr/local/bin/ld: removing unused section '.rodata' in file '/usr/lib/gcc/x86_64-redhat-linux/7/crtbegin.o' /usr/lib/rpm/debugedit build/systemd-bootchart It looks normal to me.
Created attachment 10892 [details] A patch I got [hjl@gnu-cfl-1 rhbz-1543912]$ make mkdir build /usr/gcc-8.0.1-x32/bin/gcc -I ./src -flto -B./ -O2 -g -c src/bootchart.c -o build/bootchart.o /usr/gcc-8.0.1-x32/bin/gcc -I ./src -flto -B./ -O2 -g -c src/log.c -o build/log.o /usr/gcc-8.0.1-x32/bin/gcc -flto -B./ -g -Wl,--gc-sections -Wl,--print-gc-sections \ build/bootchart.o build/log.o \ -o build/systemd-bootchart ./ld: removing unused section '.rodata.cst4' in file '/lib/../lib64/crt1.o' ./ld: removing unused section '.data' in file '/lib/../lib64/crt1.o' ./ld: removing unused section '.data' in file '/usr/gcc-8.0.1-x32/lib/gcc/x86_64-pc-linux-gnu/8.0.1/crtbegin.o' /usr/lib/rpm/debugedit build/systemd-bootchart [hjl@gnu-cfl-1 rhbz-1543912]$ I am trying to find a small test.
A patch is posted at https://sourceware.org/ml/binutils/2018-03/msg00175.html
The master branch has been updated by H.J. Lu <hjl@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9e223787a474c672c5f1cfd4574857241ae4eafa commit 9e223787a474c672c5f1cfd4574857241ae4eafa Author: H.J. Lu <hjl.tools@gmail.com> Date: Wed Mar 14 04:23:24 2018 -0700 GC: Also check the local debug definition section Extend commit b7c871edcd83ccdc5fcd8148a7f433efd6b52255 Author: H.J. Lu <hjl.tools@gmail.com> Date: Wed May 17 07:57:15 2017 -0700 Mark debug sections referenced by kept debug sections to handle the local debug definition section. bfd/ PR ld/20882 * elflink.c (elf_gc_mark_debug_section): Also check the local debug definition section. ld/ PR ld/20882 * testsuite/ld-gc/pr20882.d: Also dump and check .debug_abbrev section. * testsuite/ld-gc/pr20882b.s: Add .debug_abbrev section.
Fixed for 2.31.
The binutils-2_30-branch branch has been updated by H.J. Lu <hjl@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=da8c5cfcc9fa7fc77878ce177d1b52348ae52f26 commit da8c5cfcc9fa7fc77878ce177d1b52348ae52f26 Author: H.J. Lu <hjl.tools@gmail.com> Date: Wed Mar 14 04:23:24 2018 -0700 GC: Also check the local debug definition section Extend commit b7c871edcd83ccdc5fcd8148a7f433efd6b52255 Author: H.J. Lu <hjl.tools@gmail.com> Date: Wed May 17 07:57:15 2017 -0700 Mark debug sections referenced by kept debug sections to handle the local debug definition section. bfd/ PR ld/20882 * elflink.c (elf_gc_mark_debug_section): Also check the local debug definition section. ld/ PR ld/20882 * testsuite/ld-gc/pr20882.d: Also dump and check .debug_abbrev section. * testsuite/ld-gc/pr20882b.s: Add .debug_abbrev section. (cherry picked from commit 9e223787a474c672c5f1cfd4574857241ae4eafa)
On Wed, 14 Mar 2018, cvs-commit at gcc dot gnu.org wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=20882 > > --- Comment #21 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> --- > The binutils-2_30-branch branch has been updated by H.J. Lu > <hjl@sourceware.org>: Thanks. Verified this works for libstdc++.
(In reply to rguenther from comment #22) > On Wed, 14 Mar 2018, cvs-commit at gcc dot gnu.org wrote: > > > https://sourceware.org/bugzilla/show_bug.cgi?id=20882 > > > > --- Comment #21 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> --- > > The binutils-2_30-branch branch has been updated by H.J. Lu > > <hjl@sourceware.org>: > > Thanks. Verified this works for libstdc++. Shouldn't --gc-section tests be enabled in libstdc++ and mark them as XFAIL?
On Wed, 14 Mar 2018, hjl.tools at gmail dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=20882 > > --- Comment #23 from H.J. Lu <hjl.tools at gmail dot com> --- > (In reply to rguenther from comment #22) > > On Wed, 14 Mar 2018, cvs-commit at gcc dot gnu.org wrote: > > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=20882 > > > > > > --- Comment #21 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> --- > > > The binutils-2_30-branch branch has been updated by H.J. Lu > > > <hjl@sourceware.org>: > > > > Thanks. Verified this works for libstdc++. > > Shouldn't --gc-section tests be enabled in libstdc++ and mark them as XFAIL? Not sure how reliable we can identify those. Also we'd get XPASS then unless we have a way to check whether ld is affected by the bug or not.
(In reply to rguenther from comment #24) > > > > Shouldn't --gc-section tests be enabled in libstdc++ and mark them as XFAIL? > > Not sure how reliable we can identify those. Also we'd get > XPASS then unless we have a way to check whether ld is affected by > the bug or not. Any unknown --gc-section test failure should be investigated. If it is a linker bug, it should be fixed in linker and mark the test as XFAIL. We can use "ld --version" to check if the linker is fixed or not.
On Wed, 14 Mar 2018, hjl.tools at gmail dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=20882 > > --- Comment #25 from H.J. Lu <hjl.tools at gmail dot com> --- > (In reply to rguenther from comment #24) > > > > > > Shouldn't --gc-section tests be enabled in libstdc++ and mark them as XFAIL? > > > > Not sure how reliable we can identify those. Also we'd get > > XPASS then unless we have a way to check whether ld is affected by > > the bug or not. > > Any unknown --gc-section test failure should be investigated. If it is Which is why I reported the bug originally ... > a linker bug, it should be fixed in linker and mark the test as XFAIL. But we expect it to PASS now... > We can use "ld --version" to check if the linker is fixed or not. Yeah, but I just backported the rev. to a 2.29.1 based package so that doesn't work. You need to perform functional tests. IMHO not worth the trouble.
(In reply to rguenther from comment #26) > On Wed, 14 Mar 2018, hjl.tools at gmail dot com wrote: > > > https://sourceware.org/bugzilla/show_bug.cgi?id=20882 > > > > --- Comment #25 from H.J. Lu <hjl.tools at gmail dot com> --- > > (In reply to rguenther from comment #24) > > > > > > > > Shouldn't --gc-section tests be enabled in libstdc++ and mark them as XFAIL? > > > > > > Not sure how reliable we can identify those. Also we'd get > > > XPASS then unless we have a way to check whether ld is affected by > > > the bug or not. > > > > Any unknown --gc-section test failure should be investigated. If it is > > Which is why I reported the bug originally ... > This is exactly the problem. Yes, linker bug was reported, fixed and verified withe the provided testcase. However, the --gc-section test in libstdc++ is skipped and I didn't know that the linker fix was incomplete.
On Wed, 14 Mar 2018, hjl.tools at gmail dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=20882 > > --- Comment #27 from H.J. Lu <hjl.tools at gmail dot com> --- > (In reply to rguenther from comment #26) > > On Wed, 14 Mar 2018, hjl.tools at gmail dot com wrote: > > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=20882 > > > > > > --- Comment #25 from H.J. Lu <hjl.tools at gmail dot com> --- > > > (In reply to rguenther from comment #24) > > > > > > > > > > Shouldn't --gc-section tests be enabled in libstdc++ and mark them as XFAIL? > > > > > > > > Not sure how reliable we can identify those. Also we'd get > > > > XPASS then unless we have a way to check whether ld is affected by > > > > the bug or not. > > > > > > Any unknown --gc-section test failure should be investigated. If it is > > > > Which is why I reported the bug originally ... > > > > This is exactly the problem. Yes, linker bug was reported, fixed and > verified withe the provided testcase. However, the --gc-section test > in libstdc++ is skipped and I didn't know that the linker fix was incomplete. The test isn't skipped, I _added_ a complete run of the prettyprinter suite with -flto but without --gc-sections. There never were runs of -flto --gc-sections tests. We could add one certainly or run all -flto tests with --gc-sections as the non-lto run does. But that will turn "FAIL"ing tests into UNSUPPORTED, not FAIL, so XFAIL wouldn't work. You'd have to consciously skip the tests that would fail that way and for new "failures" you'll get UNSUPPORTED as well. The tests were supposed to verify the debug info with -flto is now sane enough to have the pretty printers work, not that the ld used works fine with --gc-sections ;)