[llvm] r176605 - Debug Info: store the files and directories for each compile unit.

[Manman Ren]

On Mon, Feb 3, 2014 at 11:28 AM, Greg Clayton <gclayton at apple.com> wrote:

> I believe the problem was that line tables had thousands of files in each
> line table prologue.
>
> Smaller is better, that is for sure. DW_AT_ranges attributes on
> DW_TAG_compile_unit tags have been useless for many years and we never
> trusted them. We always use the .debug_aranges in order to find out which
> compile unit contains which address, and even then we verify that there is
> at least a line table entry or some DWARF info for that address when we do
> think we have a match (the compile unit could claim to contain
> [0x1000-0x2000), yet there actually could be a gap in that range and if we
> found no other address information once we expanded the compile unit, we
> would continue to the next entry). This easily allowed the
> DW_TAG_compile_unit to emit a single "max" range using
> DW_AT_low_pc/DW_AT_high_pc, and then we used that as a guide. I think most
> debuggers will use the .debug_aranges when it is available. When it isn't,
> we make a manual pass through all DWARF and make it ourselves. The
> DW_AT_ranges in the compile unit is not currently considered useful or
> accurate so we really don't care what is in there beyond the accuracy of
> the "base address" that is used to compute all DW_AT_ranges and location
> list ranges for all _other_ tags in the compile unit.
>
> I am not really sure what this bug is about, so I was just guessing above
> that it was a bug that I filed back in the early LTO days where line tables
> being emitted had waaaay too many files in the prologue and many files were
> duplicated in the list.
>

We used to have a single line table for all the compile units, at r 174445
we will generate one line table for each compile unit.
The purpose is to speed up debugger as Greg explained above.

r174445 did not correctly separate the files and directories in the line
table prologue, causing all line tables have a copy of the big prologue.

r176605 fixed the issue.

Cheers,
Manman

Greg
>
> On Jan 31, 2014, at 11:07 PM, Eric Christopher <echristo at gmail.com> wrote:
>
> > I was under the impression is was a speed improvement for the
> > debugger. Having a smaller line table to look through for a given
> > compile unit would let it find a given address faster.
> >
> > That said, without ranges for compile units I'm not sure how the
> > debugger would know. We have those now, but not then.
> >
> > Greg: I'm guessing you made the request, any further insight here? :)
> >
> > -eric
> >
> > On Fri, Jan 31, 2014 at 8:20 PM, Rafael Espíndola
> > <rafael.espindola at gmail.com> wrote:
> >> Hi Manman and Eric,
> >>
> >> I started looking at what would be needed to properly represent this
> >> in a .s file in order to remove the calls to hasRawTextSupport. It
> >> looks like we would need a compilation unit id for .file and some
> >> directive that produces the offset of a given compilation unit in
> >> debug_line. Not too hard, but I am somewhat confused as to what the
> >> advantage of having multiple line tables is. From your commit message
> >> it sounds like the prologue is duplicated, but  that is not what I am
> >> seeing.
> >>
> >> As an experiment I compiled clang with lto and -gline-tables-only. The
> >> size of the resulting .debug_line section is
> >>
> >> via assembly: 0x9b6358 bytes (10.183512 MB)
> >> direct:            0xbb7a83 bytes (12.286595 MB)
> >>
> >> The version using direct object emission has 1267 line tables. The
> >> version using assembly has 1. Sure, that table has 10738 files, but it
> >> is still quiet a bit smaller than the total in the direct emission
> >> case.
> >>
> >> Cheers,
> >> Rafael
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140203/d9ed82d0/attachment.html>