[PATCH] D124892: [DWARF] Fix split dwarf debug inlining in mix mode situation.

Wed May 25 16:17:07 PDT 2022

ayermolo added a comment.

In D124892#3538807 <https://reviews.llvm.org/D124892#3538807>, @dblaikie wrote:

> In D124892#3532246 <https://reviews.llvm.org/D124892#3532246>, @ayermolo wrote:
>
>> In D124892#3529768 <https://reviews.llvm.org/D124892#3529768>, @dblaikie wrote:
>>
>>>> With ThinLTO enabled we can have a function in a CU that doesn't have split dwarf inlining enabled that gets inlined into CU that has it enabled.
>>>> When we try to lookup Abstract Scope Die for the inlined scope in constructInlinedScopeDIE, it's not present and we assert.
>>>
>>> So it seems there's probably some disconnect between the logic that adds abstract scope DIEs and the logic that looks them up? (one's using the source CU, one's using the destination CU?) - can you confirm that/which one's doing which?
>>>
>>> & maybe them consistent would be good/suitable - I guess the right behavior is probably to treat the non-split-dwarf-inlining function as having no debug info for the purposes of the place it's inlined into?
>>
>> So using this example.
>> When we are processing MachineFunction for main. We are processing SubProgram main, with CU in main.dwo. In constructAbstractSubprogramScopeDIE this is the SrcCU. It has debug inlining enabled.
>> What gets inlined in to it is Abstract Lexical Scope from helper.dwo that doesn't have debug inlining enabled.
>> Because of it we construct Abstract Subprogram Scope DIE only in SrcCU (Main DWO CU).
>>
>> With my "fix" what happens is we end up creating CU for the helper dwo, Skeleton CU for it, and adding inline subprogram information to it for "func".
>> So when we construct subprogram scope die, when constructInlinedScopeDIE is invoked on scope for func (which comes from helper.cpp), we are able to find Inlined sub program and don't crash. Because we can find Origin DIE for inlined sub program.
>>
>> Ideally I think we would like to have inlined sub program in main Skeleton CU. Otherwise it won't be complete.
>
> I think that's probably where I'm suggesting differently: If someone didn't build SrcCU with split-dwarf-inlining, then even if that code gets inlined into MainCU that /does/ have split-dwarf-inlining, it would be OK/consistent /not/ to describe the inlined function from SrcCU. I think that'd be correctly respecting the level of detail the user asked for - no symbolizing for functions in (or from) SrcCU.
>
> Could you implement that? By checking when we go to construct the inlined scope DIE if the subprogram comes from a CU without split-dwarf-inlining, and if so, skip creating the split dwarf inlined description?

Sure. Let me give it a shot next week.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124892/new/

https://reviews.llvm.org/D124892