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

[Duncan P. N. Exon Smith]

> On 2015-Mar-25, at 11:56, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> 
>> 
>> 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?
> 

On the contrary, I think I found a way to CHECK the line tables
directly (in a platform-neutral way); see r233207.