Debug info: test crashes at -O0

Project Infrastructure LLVM Dev List Archives
1

Hi Duncan,

For one of my tasks I am checking the LLVM tests with -O0 passed to llc.

There are some llc crashes and one of them happens on the CodeGen/ARM/debug-info-d16-reg.ll test. It has two DILocalVariable's with the same arg number:

!50 = !DILocalVariable(tag: DW_TAG_arg_variable, name: "val", line: 4, arg: 2, scope: !9, file: !1, type: !7)
!51 = !DILocalVariable(tag: DW_TAG_arg_variable, name: "c", line: 4, arg: 2, scope: !9, file: !1, type: !8).

This breaks the assert condition "assert(V.Var == Var && "conflicting variable")" in DbgVariable::addMMIEntry, as the two entries ("c" and "val") with different DILocalVariable* pointers are added to the same DbgVariable. In release build it crashes later on a null pointer dereference.

Although this is an obvious mistake as the IR is handwritten, it might be a good idea to adjust the code so that it doesn't crash and shows a comprehensive error message instead.

Would you share you thoughts whether this makes sense, please?

Thanks.
Oleg

2

Hi Duncan,

For one of my tasks I am checking the LLVM tests with -O0 passed to llc.

There are some llc crashes and one of them happens on the CodeGen/ARM/debug-info-d16-reg.ll test. It has two DILocalVariable's with the same arg number:

!50 = !DILocalVariable(tag: DW_TAG_arg_variable, name: "val", line: 4, arg: 2, scope: !9, file: !1, type: !7)
!51 = !DILocalVariable(tag: DW_TAG_arg_variable, name: "c", line: 4, arg: 2, scope: !9, file: !1, type: !8).

This breaks the assert condition "assert(V.Var == Var && "conflicting variable")" in DbgVariable::addMMIEntry, as the two entries ("c" and "val") with different DILocalVariable* pointers are added to the same DbgVariable. In release build it crashes later on a null pointer dereference.

Although this is an obvious mistake as the IR is handwritten,

Looking at `git log`, I doubt this was handwritten. Just old (r129934),
and likely suffering from bitrot.

it might be a good idea to adjust the code so that it doesn't crash and shows a comprehensive error message instead.

Would you share you thoughts whether this makes sense, please?

Yup, a misbehaving frontend could easily generate this IR. I think the
`Verifier` is the right place to catch this. Thanks for working on it!