This is the mail archive of the
mailing list for the binutils project.
Re: RFC: Generating per-function DWARF line number sections
- From: Cary Coutant <ccoutant at google dot com>
- To: nick clifton <nickc at redhat dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Tue, 30 Apr 2013 11:46:55 -0700
- Subject: Re: RFC: Generating per-function DWARF line number sections
- References: <87haiyppev dot fsf at redhat dot com> <20130426021535 dot GB31074 at bubble dot grove dot modra dot org> <517A34F3 dot 2040002 at redhat dot com> <517E78A1 dot 2050505 at redhat dot com>
> I have now checked the patch in, with a couple of minor tweaks:
> * I added an entry in gas/NEWS.
> * The quadratic loop in elflink.c:_bfd_elf_gc_mark_extra_sections is now
> only run if the input bfd contains one of new fragmentary .debug_line
This doesn't play well with .dwo files:
if (const_strneq (section->name, ".debug_line."))
/* Sections named .debug_line.<foo> are fragments of a .debug_line
section containing just the Line Number Statements. They are
created by the assembler and intended to be used alongside gcc's
-ffunction-sections command line option. When the linker's
garbage collection decides to discard a .text.<foo> section it
can then also discard the line number information in
Since the section is a fragmnent it does not have the details
needed to fill out a LineInfo structure, so instead we use the
details from the last one we processed. */
If we have a .debug_line.dwo section, readelf will treat that as a
fragment, and will not parse the section correctly. We end up with a
divide-by-zero error when trying to dump the section.
I think we need a better way of identifying fragments of a debug
sections. What if someone has a function named "dwo"?