https://llvm.org/bugs/show_bug.cgi?id=30703
Bug ID: 30703
Summary: SROA sometimes breaks local variable debuginfo that
uses DIExpression
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: michaelwoeris...@posteo.net
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
In the Rust compiler, closures are translated into regular functions with the
closure environment passed in as the first function parameter. These
environments are structs containing the variables that have been captured by
the closure. Each captured variable can either be contained in the environment
struct directly (by value), or the environment contains a pointer to where the
captured variable actually lives.
When generating debuginfo for closures, we want captured variables to appear
like regular locals. To this end we use a `@llvm.dbg.declare()` that points to
the alloca containing the environment struct and that has a DIExpression
navigating to field in question (via a DW_OP_plus) and, if needed, doing a
DW_OP_deref. This works well in most cases, but sometimes SROA will produce
bitcode that fails verification with an error like:
piece is larger than or outside of variable
call void @llvm.dbg.value(metadata { i8*, i64 }* %arg0.sroa.5.0.copyload, i64
0, metadata !361, metadata !370), !dbg !368
!361 = !DILocalVariable(name: "buf", scope: !313, file: !30, line: 1, type:
!341)
!370 = !DIExpression(DW_OP_bit_piece, 128, 64)
So far, we have been able to work around this by always creating an additional
alloca containing a pointer to the environment struct and then using that as
the starting point for computing the variables' location in the DIExpression.
SROA seems to be able to handle this case in a more reliable way. However, we'd
like to get rid of this additional alloca that is just introduced for the sake
of debuginfo.
We have managed to create a rather small test case for reproducing this:
https://gist.github.com/michaelwoerister/55aed8d38be97c404b31c091cbb37ebd
bugpoint reduced this further (it fails for a different variable there, one
that does not have a DW_OP_plus, but with the same assertion):
https://gist.github.com/michaelwoerister/8dba37e51a4dc17413229770081d2c76
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
