ld --gc-sections not removing debug sections

Hi Henry,

Can you be more specific on "related debug sections"? As there are some different kinds of debug sections like .debug_aranges section, .debug_info section, .debug_abbrev section, .debug_line section and etc., when we run command "arm-none-eabi-readelf -w test.out" to get debug sections.

As far as I know it isn't one debug section for one function. Instead all debug information are classified and stored in one section, such as the .debug_info section stores dwarf information for all functions including the removed one. In another word, the debug information related to the removed function is just an entry of certain debug section. So I guess you mean to remove the related debug entry rather than the debug section.

I tried the patch you mentioned and Binutils 2.22, I didn't find there is some debug section got removed.

BR,
Terry

Hi Terry,

Thanks for the quick response. Sorry about the wording. Yes I was referring to the dwarf entries inside .debug_info,.debug_abbrev,.debug_loc etc. for the function that has been deadstripped. I'm also using the compile option -ffunction-sections -fdata-sections to facilitate better deadstripping but yes all the debug entries is still within one single debug section for each object file.

Thanks,
Henry

Hi Henry,

I just cross built a tool chain from the latest GCC trunk and Binutils trunk. With this tool chain and options "-ffunction-sections -fdata-sections -Wl,--gc-sections", the debug entries of deadstripped functions are still there. So I think your concern becomes something related to a fundamental questions "why gcc still remain debug entry of deadstripped function".

I will raise this question to gcc community. So there will be no back port for upcoming release.

binutils 2.24 has a "fix" for this problem - the assembler supports a --gdwarf-sections option to generate debug_line sections on a per-function basis, and the linker then discards the corresponding debug_line section when it discards a function section. Here's the commit id and details on the git repo (git://sourceware.org/git/binutils.git).

Could this be backported please, considering the 4.8 release with binutils 2.23.2 does not have this fix?

commit 4aeab24fbfecac381c5cd91be5f68a77733a3943
Author: Nick Clifton <email address hidden>
Date: Mon Apr 29 13:38:57 2013 +0000

        * elflink.c (_bfd_elf_gc_mark_extra_sections): Remove mark from
        fragmented .debug_line sections associated with unmarked code
        sections.

        * dwarf.c (read_debug_line_header): New function. Reads in a
        header in a .debug_line section.
        (display_debug_lines_raw): Use new function. Handle fragmentary
        .debug_line sections.
        (display_debug_lines_decoded): Likewise.
        * readelf.c (process_section_headers): Handle fragmenatry
        .debug_line sections.
        (display_debug_section): Likewise.

        * as.c (Options): Add -gdwarf-sections.
        (parse_args): Likewise.
        * as.h (flag_dwarf_sections): Declare.
        * dwarf2dbg.c (emit_fixed_inc_line_addr): Skip section changes.
        (process_entries): When -gdwarf-sections is enabled generate
        fragmentary .debug_line sections.
        (out_debug_line): Set the section for the .debug_line section end
        symbol.
        * doc/as.texinfo: Document -gdwarf-sections.
        * NEWS: Mention -gdwarf-sections.

        * gas/elf/dwarf2-3.d: Fix expected readelf output.

        * scripttempl/DWARF.sc: Add support for .debug_line.* and
        .debug_line_end.

Very appreciate for reminding this. It looks like a few of files are involved in this fix. Let me check if 2.23 is ready for this backporting.

Sorry for later response. I just looked into and tried out the patch. The relevant patch introduction from author is at https://sourceware.org/ml/binutils/2013-04/msg00229.html. As said in introduction, it doesn't solve the issue completely. It just removes the dead information from .debug_line section. The dead function information can still be found in .debug_info section.
The patch can't be applied to 2.23 directly and smoothly, some other local adjustment works are needed.

Considering its limited function, I am kind of tentative to back port it.