[llvm-bugs] [Bug 49144] New: Multiple debug variables sharing a stack slot are incorrectly formatted in MIR

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=49144

            Bug ID: 49144
           Summary: Multiple debug variables sharing a stack slot are
                    incorrectly formatted in MIR
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: stephen.tozer at sony.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 24514
  --> https://bugs.llvm.org/attachment.cgi?id=24514&action=edit
Call with llc -run-pass=stack-coloring to reproduce; also functions as a lit
test.

This is a bug that occurs when we have two (or more) stack slots that have
associated debug declares, and the stack coloring pass merges them so that we
have a stack slot with multiple debug declares. Instead of printing them out as
a list of some kind, we simply print them off adjacent in a syntactically
invalid format; attempting to parse the resulting MIR simply results in a
crash.

For example, from the reproducer:

stack:
  - { id: 0, ...,
      debug-info-variable: '!4', debug-info-expression: '!DIExpression()', 
      debug-info-location: '!7' }
  - { id: 1, ..., 
      debug-info-variable: '!8', debug-info-expression: '!DIExpression()', 
      debug-info-location: '!7' }

llc -run-pass=stack-coloring reproducer.mir

stack:
  - { id: 0, ...,
      debug-info-variable: '!4!8', debug-info-expression:
'!DIExpression()!DIExpression()',
      debug-info-location: '!7!7' }

This issue can be traced back to MIRPrinter::printStackObjectDbgInfo, and its
single caller MIRPrinter::convertStackObjects. In these functions, we iterate
through the VariableDbgInfo for the function, fetch the string streams for the
associated stack slots, and append the debug info to those. Instead of simply
directly appending, there should be some kind of separator if a value has
already been written to the stream; the parser will also need to be updated to
support this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210211/f1f6622c/attachment.html>