This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Generating per-function DWARF line number sections


>   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
> sections.

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
.debug_line.<foo>.

             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"?

-cary


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]