Cannot represent a difference across sections due to debuginfo

[nikic]

Running https://gist.github.com/nikic/6f60958ed4295f0bcd48797b5e541aba through llc -filetype=obj we get errors like this:

<unknown>:0: error: Cannot represent a difference across sections
<unknown>:0: error: Cannot represent a difference across sections
<unknown>:0: error: Cannot represent a difference across sections
<unknown>:0: error: Cannot represent a difference across sections

This is related to the debug info in some way.

[llvmbot]

@llvm/issue-subscribers-debuginfo

[nikic]

Bisected to d20e4a1. cc @dianqk @dwblaikie

[jmorse]

It looks like test2 being "cold" controls this -- looking at the textual assembly, .debug_ranges is being generated thus:

.Ldebug_ranges0:
    .quad   .Ltmp0-.Lfunc_begin1
    .quad   .Ltmp1-.Lfunc_begin1
    .quad   .Ltmp2-.Lfunc_begin1
    .quad   .Ltmp3-.Lfunc_begin1

Where the temporary symbols are in the test1 function, and .Lfunc_begin1 is the start of test2. test2 ends up in a different section to test1, so this is an illegal cross-section reference.

Exactly why this happens is pretty unclear though: if I move test2 to the start of the input file, .debug_ranges still tries to describe test1 in terms of the end of test2, so there's something in the debug-info metadata that causes the two to be connected. test1's scope appears to be deeply buried in some types that are used for the global variable in !8, which is in CU !4's retained_nodes list. However, test1 says that it belongs to CU !1. Breaking this connection at various points in the type-scope chain, or test1's CU, makes the error go away. This gives me the impression that this is a debug-info deduplication / linking error? Exactly how that translates to test1's .debug_ranges connecting to another function still isn't clear.

(The type hierarchy metadata isn't my strong point).

[dianqk]

It may be time to apply https://reviews.llvm.org/P8297 to solve various such problems. @dwblaikie
I will address why this happened as soon as possible to decide what to do next.

[dianqk]

@nikic @jmorse I probably figured out why the debug info is often inconsistent under LTO here.
We solved some issues by determining the CU based on the parent DIE. So I want to apply the P8297 patch. I have added more construct method adjustments based on P8297. But it didn't solve the issue.

But we should still consider applying the idea of P8297 while putting the method of constructing the DIE into DwarfDebug. I had a headache switching CU debugging in DwarfCompileUnit.cpp.

The core issue I found is that DISubprogram operations usually use getUnit, while its DIE uses getScope. Once these two are associated with different CUs, associated DIEs may use another CU.

If we can make the associated CU for each DIE unambiguous, these kinds of problems should all go away. But what are the rules for determining who the parent DIE of a DIE is? Ignoring the unit and following the scope chain might be the way to go.

I have created a patch that is just working.