[llvm] r233165 - Linker: Temporarily disable dwarfdump checks from r233164

[Duncan P. N. Exon Smith]

> On 2015-Mar-25, at 10:50, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Wed, Mar 25, 2015 at 10:45 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> 
> > On 2015-Mar-25, at 10:24, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> >
> >>
> >> On 2015-Mar-25, at 10:12, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> >>
> >> Good point, I guess I'm not being very creative :/.  Peter also obliged
> >> [1] my request for a dump on Linux, which I've reproduced locally by
> >> specifying -mtriple=x86_64-unknown-linux.  What's going wrong is the
> >> second compile unit is missing the subprogram for the weak ("winning")
> >> function.
> >>
> >> [1]: https://llvm.org/bugs/show_bug.cgi?id=22792#c7 "Output on Linux"
> >>
> >> This DWARF is wrong, right?  (I.e., are the expected differences in
> >> debug info between Linux and Darwin all in the frontend generation
> >> logic?)
> >
> > Just talked to Adrian offline; answer is "yes".  I'll see if I can figure
> > this out and just revert r233165.
> 
> Interestingly, in assembly both darwin and linux are "missing" things.
> 
> On darwin, we get the subprogram for the smaller compile unit, but not
> the compile unit.
> 
> Not sure if relevant, but Darwin's linker or something likes to drop CUs with no subprograms... (I hit this when improving -gmlt output size)

Found the cause in `DwarfDebug::endFunction()`, added in r218129:

    // Under -gmlt, skip building the subprogram if there are no inlined
    // subroutines inside it.
    if (TheCU.getCUNode().getEmissionKind() == DIBuilder::LineTablesOnly &&
        LScopes.getAbstractScopesList().empty() && !IsDarwin) {
      assert(InfoHolder.getScopeVariables().empty());
      assert(DbgValues.empty());
      // FIXME: This wouldn't be true in LTO with a -g (with inlining) CU followed
      // by a -gmlt CU. Add a test and remove this assertion.
      assert(AbstractVariables.empty());
      LabelsBeforeInsn.clear();
      LabelsAfterInsn.clear();
      PrevLabel = nullptr;
      CurFn = nullptr;
      return;
    }

Added in r218129.  Note the `IsDarwin` flag, whose logic was added in
r218129:

    Disable the -gmlt optimization implemented in r218129 under Darwin due to issues with dsymutil.
    
    r218129 omits DW_TAG_subprograms which have no inlined subroutines when
    emitting -gmlt data. This makes -gmlt very low cost for -O0 builds.
    
    Darwin's dsymutil reasonably considers a CU empty if it has no
    subprograms (which occurs with the above optimization in -O0 programs
    without any force_inline function calls) and drops the line table, CU,
    and everything in this situation, making backtraces impossible.
    
    Until dsymutil is modified to account for this, disable this
    optimization on Darwin to preserve the desired functionality.
    (see r218545, which should be reverted after this patch, for other
    discussion/details)
    
    Footnote:
    In the long term, it doesn't look like this scheme (of simplified debug
    info to describe inlining to enable backtracing) is tenable, it is far
    too size inefficient for optimized code (the DW_TAG_inlined_subprograms,
    even once compressed, are nearly twice as large as the line table
    itself (also compressed)) and we'll be considering things like Cary's
    two level line table proposal to encode all this information directly in
    the line table.

So I guess the difference is expected, and this test needs to be
target-specific?