[llvm] r200422 - Turn on CU ranges if we've got multiple compile units in the same

David Blaikie dblaikie at gmail.com
Wed Jan 29 14:53:56 PST 2014 

On Wed, Jan 29, 2014 at 2:41 PM, Eric Christopher <echristo at gmail.com>wrote:

> On Wed, Jan 29, 2014 at 2:37 PM, Eric Christopher <echristo at gmail.com>
> wrote:
> > On Wed, Jan 29, 2014 at 2:32 PM, David Blaikie <dblaikie at gmail.com>
> wrote:
> >>
> >>
> >>
> >> On Wed, Jan 29, 2014 at 2:26 PM, Eric Christopher <echristo at gmail.com>
> >> wrote:
> >>>
> >>> On Wed, Jan 29, 2014 at 2:23 PM, David Blaikie <dblaikie at gmail.com>
> wrote:
> >>> >
> >>> >
> >>> >
> >>> > On Wed, Jan 29, 2014 at 2:06 PM, Eric Christopher <
> echristo at gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> Author: echristo
> >>> >> Date: Wed Jan 29 16:06:27 2014
> >>> >> New Revision: 200422
> >>> >>
> >>> >> URL: http://llvm.org/viewvc/llvm-project?rev=200422&view=rev
> >>> >> Log:
> >>> >> Turn on CU ranges if we've got multiple compile units in the same
> >>> >> module since there's no range guarantee that we could make given
> >>> >> output order. This also fixes up the testcases that have multiple
> >>> >> CUs to have the correct range offset.
> >>> >
> >>> >
> >>> > What if LTO together a debug and non-debug module together? We'll
> still
> >>> > have
> >>> > one CU, but we'll have functions that aren't in that CU - and
> >>> > incorrectly
> >>> > describe that using an "all text" range?
> >>> >
> >>>
> >>> ... Short of saying "always use DW_AT_ranges" I don't have a good
> >>> solution for this. I'm somewhat down with that, but...
> >>
> >>
> >> Perhaps you were addressing this with the "there's no range guarantee
> that
> >> we could make given output order" (I'm not /quite/ sure how to parse
> that
> >> sentence) - but I thought we'd settled on the idea that we could rely on
> >> output order and just coalesce functions/ranges that came one after the
> >> other. Or did you come up with some cases that breaks down for/that we
> care
> >> about?
> >>
> >
> > If you have functions that aren't associated with a particular CU
> > there's no way of knowing which functions those are. We can only rely
> > on the output order to determine whether or not a function is not
> > going to appear in debug info output. At least not at the moment. I
> > imagine if we were to do so we'd run into the assert at
> > DwarfDebug.cpp:1583 right now if we even tried linking the two modules
> > together. :\
>
> FWIW we don't seem to. Wacky.
>

Guess we must be exiting around DwarfDebug.cpp:15671, but not sure.


> Anyhow, continuing down the unified range path.
>

OK - sorry, wasn't clear whether you were pursuing that or whether this
patch was an alternative. (given that I don't think this patch should be
needed if the unified range stuff works, I assumed this was an alternative)

- Dave


>
> -eric
>
> >
> >> That way we'd still get high/low whenever it's contiguous, and otherwise
> >> we'd use ranges.
> >>
> >
> > Still don't have this way of doing it in yet, but that's an idea yes.
> > I'll see how it works in practice.
> >
> > -eric
> >
> >>>
> >>>
> >>> -eric
> >>>
> >>> >>
> >>> >>
> >>> >> Modified:
> >>> >>     llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
> >>> >>
> llvm/trunk/test/DebugInfo/X86/stmt-list-multiple-compile-units.ll
> >>> >>
> >>> >> Modified: llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
> >>> >> URL:
> >>> >>
> >>> >>
> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp?rev=200422&r1=200421&r2=200422&view=diff
> >>> >>
> >>> >>
> >>> >>
> ==============================================================================
> >>> >> --- llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp (original)
> >>> >> +++ llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp Wed Jan 29
> >>> >> 16:06:27
> >>> >> 2014
> >>> >> @@ -1119,10 +1119,12 @@ void DwarfDebug::endSections() {
> >>> >>    }
> >>> >>
> >>> >>    // For now only turn on CU ranges if we've explicitly asked for
> it,
> >>> >> -  // we have -ffunction-sections enabled, or we've emitted a
> function
> >>> >> -  // into a unique section. At this point all sections should be
> >>> >> finalized
> >>> >> -  // except for dwarf sections.
> >>> >> -  HasCURanges = DwarfCURanges || UsedNonDefaultText ||
> >>> >> +  // we have -ffunction-sections enabled, we've emitted a function
> >>> >> +  // into a unique section, or we're using LTO. If we're using LTO
> >>> >> then
> >>> >> +  // we can't know that any particular function in the module is
> >>> >> correlated
> >>> >> +  // to a particular CU and so we need to be conservative. At this
> >>> >> point
> >>> >> all
> >>> >> +  // sections should be finalized except for dwarf sections.
> >>> >> +  HasCURanges = DwarfCURanges || UsedNonDefaultText ||
> (CUMap.size() >
> >>> >> 1)
> >>> >> ||
> >>> >>                  TargetMachine::getFunctionSections();
> >>> >>  }
> >>> >>
> >>> >>
> >>> >> Modified:
> >>> >> llvm/trunk/test/DebugInfo/X86/stmt-list-multiple-compile-units.ll
> >>> >> URL:
> >>> >>
> >>> >>
> http://llvm.org/viewvc/llvm-project/llvm/trunk/test/DebugInfo/X86/stmt-list-multiple-compile-units.ll?rev=200422&r1=200421&r2=200422&view=diff
> >>> >>
> >>> >>
> >>> >>
> ==============================================================================
> >>> >> ---
> llvm/trunk/test/DebugInfo/X86/stmt-list-multiple-compile-units.ll
> >>> >> (original)
> >>> >> +++
> llvm/trunk/test/DebugInfo/X86/stmt-list-multiple-compile-units.ll
> >>> >> Wed
> >>> >> Jan 29 16:06:27 2014
> >>> >> @@ -8,11 +8,11 @@
> >>> >>  ; CHECK: .debug_info contents:
> >>> >>  ; CHECK: DW_TAG_compile_unit
> >>> >>  ; CHECK: DW_AT_stmt_list [DW_FORM_sec_offset]   (0x00000000)
> >>> >> -; CHECK: DW_AT_low_pc [DW_FORM_addr]       (0x0000000000000000)
> >>> >> +; CHECK: DW_AT_ranges [DW_FORM_sec_offset]      (0x00000000)
> >>> >>
> >>> >>  ; CHECK: DW_TAG_compile_unit
> >>> >>  ; CHECK: DW_AT_stmt_list [DW_FORM_sec_offset]   (0x0000003c)
> >>> >> -; CHECK: DW_AT_low_pc [DW_FORM_addr]       (0x0000000000000000)
> >>> >> +; CHECK: DW_AT_ranges [DW_FORM_sec_offset]      (0x00000020)
> >>> >>
> >>> >>  ; CHECK: .debug_line contents:
> >>> >>  ; CHECK-NEXT: Line table prologue:
> >>> >> @@ -25,12 +25,12 @@
> >>> >>
> >>> >>  ; DWARF3: .debug_info contents:
> >>> >>  ; DWARF3: DW_TAG_compile_unit
> >>> >> -; DWARF3: DW_AT_stmt_list [DW_FORM_data4]   (0x00000000)
> >>> >> -; DWARF3: DW_AT_low_pc [DW_FORM_addr]       (0x0000000000000000)
> >>> >> +; DWARF3: DW_AT_stmt_list [DW_FORM_data4]    (0x00000000)
> >>> >> +; DWARF3: DW_AT_ranges [DW_FORM_data4]       (0x00000000)
> >>> >>
> >>> >>  ; DWARF3: DW_TAG_compile_unit
> >>> >>  ; DWARF3: DW_AT_stmt_list [DW_FORM_data4]   (0x0000003c)
> >>> >> -; DWARF3: DW_AT_low_pc [DW_FORM_addr]       (0x0000000000000000)
> >>> >> +; DWARF3: DW_AT_ranges [DW_FORM_data4]      (0x00000020)
> >>> >>
> >>> >>  ; DWARF3: .debug_line contents:
> >>> >>  ; DWARF3-NEXT: Line table prologue:
> >>> >>
> >>> >>
> >>> >> _______________________________________________
> >>> >> 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/20140129/d7e8a4bc/attachment.html>

More information about the llvm-commits mailing list