This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo] Fix crash when emitting an invalidated SDDbgValue
ClosedPublic

Authored by StephenTozer on Apr 29 2021, 8:28 AM.

Details

Summary

This patch resolves an issue reported in review https://reviews.llvm.org/D91722 (post-commit). The error in this case is simple: during the lambda function hasUnknownVReg, used to determine whether an SDDbgValue has any unresolved VReg arguments, constructs an SDValue from any SDNode operands to the debug value. The constructor for an SDValue asserts that it is a valid value; this means that when a debug value has an invalid operand, this check will trigger that assertion and crash the compiler.

The solution in this patch is to only perform this check if !SDDbgValue->isInvalidated(); the check is irrelevant for an invalidated debug value in the first place, because we will set all of its operands to undef, so it doesn't matter whether any of its arguments are unresolved at that point. This check is not used to determine the "correct" insert location for a DBG_VALUE, only the first location where it can be valid, so there should be no harm in short-circuiting this way.

Diff Detail

Event Timeline

StephenTozer created this revision.Apr 29 2021, 8:28 AM
StephenTozer requested review of this revision.Apr 29 2021, 8:28 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 29 2021, 8:28 AM

Remove git hash and directory path from test case metadata.

Orlando added a comment.EditedApr 29 2021, 11:41 AM

The change makes sense and LGTM.

Is the test relying on a debug info bug happening I wonder? If so, that would make the test slightly fragile (assuming that bugs will eventually get fixed). Looking at the generated MIR there seems to be a 1:1 mapping of IR to MIR instructions, which I think suggests that the SDDbgValue wasn't updated at some point.

I had a play with this and I've manged to further reduce the test. You can replace the function body with this:

define dso_local i32 @intel_pmu_enable_bts() local_unnamed_addr !dbg !16 {
entry:
  %0 = extractvalue { i32, i64 } zeroinitializer, 1
  %1 = load i32, i32* @intel_pmu_enable_bts_config, align 4
  call void @llvm.dbg.value(metadata !DIArgList(i64 %0, i32 %1), metadata !20, metadata !DIExpression(DW_OP_LLVM_arg, 0, DW_OP_LLVM_arg, 1, DW_OP_or, DW_OP_stack_value)), !dbg !23
  ret i32 %1
}

I guess the test case is may not relying on a "bug" - it feels similar to the situation in IR when an instruction is deleted, the pass doesn't call salvageDebugInfo, and Instructions dtor defensively sets metadata uses to undef. The debug info isn't incorrect, it's just worse than it needs to be. I would be happier if we could generate a test for this which doesn't rely on this kind of thing, because if the underlying issue is fixed the test might become hard to regenerate, but maybe this code path is only ever hit that way? I'm not sure.

EDIT: Sorry, my concern about the test was unfounded. I managed to miss that %asmresult1 isn't used anywhere other than in the dbg.value and subsequently and subsequently doesn't make it through to MIR.

llvm/test/DebugInfo/Generic/invalidated-dbg-value-is-undef.ll
13

You could add --implicit-check-not=DBG_VALUE to FileCheck and remove the CHECK-NOTs? No strong opinion on this though.

Update test case with further reduced function body and implicit-check-not.

Orlando accepted this revision.Apr 30 2021, 1:07 AM
Orlando added a subscriber: jmorse.

LGTM but please wait a little to see if anyone else has comments on the test, cc @jmorse.

This revision is now accepted and ready to land.Apr 30 2021, 1:07 AM
This revision was landed with ongoing or failed builds.May 7 2021, 5:14 AM
This revision was automatically updated to reflect the committed changes.

This patch caused some failures on buildbots, caused by the fact that the test requires x86_64 but does not have the explicit REQUIRE set. I've pushed up a followup fix that moves the test from DebugInfo/Generic to DebugInfo/X86, which should fix the issue; I welcome any post-commit review on this change.

This patch caused some failures on buildbots, caused by the fact that the test requires x86_64 but does not have the explicit REQUIRE set. I've pushed up a followup fix that moves the test from DebugInfo/Generic to DebugInfo/X86, which should fix the issue; I welcome any post-commit review on this change.

Might be handy to include the commit hash so folks can easily follow-up from here to there. (I think there's some way to write the commit hash in Phab such it it turns it into a link, which is nice)

Might be handy to include the commit hash so folks can easily follow-up from here to there. (I think there's some way to write the commit hash in Phab such it it turns it into a link, which is nice)

Thanks for the heads up; the commit hash for the fix is 14818a86d044909d8eeb1f39f689e2785a09823b.