This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo] Include DW_TAG_skeleton_unit when looking for parent UnitDie
ClosedPublic

Authored by wenlei on Feb 25 2022, 11:17 PM.

Details

Summary

DIE::getUnitDie looks up parent DIE until compile unit or type unit is found. However for skeleton CU with debug fission, we would have DW_TAG_skeleton_unit instead of DW_TAG_compile_unit as top level DIE.

This change fixes the look up so we can get DW_TAG_skeleton_unit as UnitDie for skeleton CU.

Diff Detail

Event Timeline

wenlei created this revision.Feb 25 2022, 11:17 PM
wenlei requested review of this revision.Feb 25 2022, 11:17 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 25 2022, 11:17 PM

This should include a test - and could you describe more about where this issue came up/what motivated the change?

wenlei updated this revision to Diff 414251.Mar 9 2022, 5:38 PM

Add test case.

Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptMar 9 2022, 5:38 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
wenlei added a comment.Mar 9 2022, 5:54 PM

This should include a test - and could you describe more about where this issue came up/what motivated the change?

Sure, sorry for the delay as I just got back to this today. I sent the fix first hoping to get a sanity check as we were a bit puzzled how come nobody hit this in the past.

Here's what happened for the ICE - we needed to add template types when constructing subprogram die for template functions (addTemplateParams) for the skeleton CU, this is done through getOrCreateContextDIE which involves finding/creating parent DIEs. For that, we sometimes need to retrieve top level DIE (getOrCreateContextDIE -> getUnitDie). Before this fix, we end up with nullptr from getUnitDie, so some DIEs created in that process has getUnit() being null which leads to ICE on access.

I added a test case that would cause ICE without this fix (the set of flags there is minimum).

Fixes in LLVM require tests in LLVM - probably taking the clang test and compiling that to llvm IR (include the original C++ source in a comment in the IR test case) and then testing it in LLVM instead of clang.

Also looks like the test could be simplified a bit more:

void f1();

template <typename T>
void f2() {
  f1();
}

void f3() {
  f2<int>();
}
wenlei updated this revision to Diff 414606.Mar 11 2022, 12:32 AM

update test case

Fixes in LLVM require tests in LLVM - probably taking the clang test and compiling that to llvm IR (include the original C++ source in a comment in the IR test case) and then testing it in LLVM instead of clang.

Also looks like the test could be simplified a bit more:

void f1();

template <typename T>
void f2() {
  f1();
}

void f3() {
  f2<int>();
}

Done, thanks.

It'd be good to include some testing beyond "does not crash" - like what was the specific debug info we were trying to create when the crash was hit? Perhaps we should be testing that (since the crash demonstrates we weren't testing that anywhere else)

wenlei updated this revision to Diff 414737.Mar 11 2022, 1:25 PM

Add test check for template type parameters

It'd be good to include some testing beyond "does not crash" - like what was the specific debug info we were trying to create when the crash was hit? Perhaps we should be testing that (since the crash demonstrates we weren't testing that anywhere else)

Sure, added a few checks around DW_TAG_template_type_parameter for both DW_TAG_skeleton_unit and DW_TAG_skeleton_unit. Let me know whether what I have here aligns with the convention of similar tests.

dblaikie accepted this revision.Mar 12 2022, 12:31 PM

Thanks, sounds good!

This revision is now accepted and ready to land.Mar 12 2022, 12:31 PM

@wenlei Thanks for digging in to this!