<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - LLVM may create invalid DWARF 4+ expressions"
href="https://bugs.llvm.org/show_bug.cgi?id=32382">32382</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>LLVM may create invalid DWARF 4+ expressions
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>DebugInfo
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>aprantl@apple.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>As I recently confirmed on a thread on the dwarf-discuss mailing list
(<a href="http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/2017-March/004335.html">http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/2017-March/004335.html</a>),
LLVM's DwarfExpression implementation can generate illegal DWARF 4+. This
hasn't been noticed thus far, because for relatively simple DWARF expressions
the difference doesn't matter, but as we get better about preserving debug
locations, this is becoming urgent.
To give a simplified overview, DWARF 4+ location descriptions come in multiple
flavors:
- Register location descriptions
- describe a variable in a register
- consist of only a DW_OP_reg
- Memory location descriptions
- describe the address of a variable
- Implicit location descriptions
- describe the value of a variable
- end with DW_OP_stack_value & friends
- Composite location descriptions
- use DW_OP_piece & friends to combine multiple location
descriptions of any of the previous kinds
Based on this, there are three main problems with LLVM's implementation:
1. DW_OP_reg is not allowed outside of register location descriptions.
2. We are sometimes missing a DW_OP_stack_value.
2a. In DWARF 2&3 we should not emit anything that needs a
DW_OP_stack_value that is not a constant.
3. LLVM uses DW_OP_breg when it means "deref the contents of that register",
which is only correct if no arithmetic operators follow.
Because of the missing DW_OP_stack_value the location will be classified as
a memory location description and thus it usually works out.
In the last couple of days I refactored DwarfExpression to make fixing all of
these issues easy. We can now defer the decision on which kind of location
description to emit (and thus whether to use DW_OP_reg vs. DW_OP_breg
(+DW_OP_stack_value)) until we know the remainder of the expression.
The bugfixes won't affect any straightforward location descriptions (i.e.:
DW_OP_(b)reg without any operators, and DW_OP_breg DW_OP_deref will remain the
same) so I'm not expecting any dramatic fallout from fixing this PR, but please
do keep an eye on your debugger bots and let me know if your tools have come to
depend on LLVM bugs and we need to do some debugger tuning to make things work.
I will keep an eye on LLDB and make sure that it doesn't suffer from the same
problems as LLVM.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>