<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 - Variable with end part that is optimized out is printed incorrectly"
href="https://bugs.llvm.org/show_bug.cgi?id=41885">41885</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Variable with end part that is optimized out is printed incorrectly
</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>Linux
</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>david.stenberg@ericsson.com
</td>
</tr>
<tr>
<th>CC</th>
<td>jdevlieghere@apple.com, keith.walker@arm.com, llvm-bugs@lists.llvm.org, paul_robinson@playstation.sony.com
</td>
</tr></table>
<p>
<div>
<pre>When compiling the following example:
extern int ext;
volatile int global;
int main() {
int arr[32] = {123};
global = arr[0];
arr[0] = ext;
return 0;
}
with Clang (trunk) respectively GCC (8.3.0), you get different location
information about the optimized out elements at the end of arr:
$ clang -O3 -g opt-end.c -o clang.out
$ llvm-dwarfdump clang.out | grep -B2 -P "DW_AT_name.*arr"
DW_AT_location (0x00000000
[0x0000000000400480, 0x000000000040048a): DW_OP_constu
0x7b, DW_OP_stack_value, DW_OP_piece 0x4)
DW_AT_name ("arr")
$ gcc-8 -O3 -g -gstrict-dwarf opt-end.c -o gcc.out
$ llvm-dwarfdump gcc.out | grep -A5 -P "DW_AT_name.*arr" | grep -vP
"DW_AT_decl|DW_AT_type"
DW_AT_name ("arr")
DW_AT_location (0x00000000
[0x00000000000004f0, 0x00000000000004fa): DW_OP_const1u
0x7b, DW_OP_stack_value, DW_OP_piece 0x4, DW_OP_piece 0x7c)
As seen, GCC emits an explicit empty location description piece which covers
the optimized out elements at the end of the array, whereas Clang does not emit
that.
This results in the elements being printed out with garbage data when debugging
the Clang binary in LLDB (7.0):
$ lldb-7 clang.out
(lldb) target create "clang.out"
Current executable set to 'clang.out' (x86_64).
(lldb) b main
Breakpoint 1: where = clang.out`main at opt-end.c:6, address =
0x0000000000400480
(lldb) run
Process 22244 launched: '/home/edasten/upstream/master/clang.out' (x86_64)
Process 22244 stopped
* thread #1, name = 'clang.out', stop reason = breakpoint 1.1
frame #0: 0x0000000000400480 clang.out`main at opt-end.c:6
3
4 int main() {
5 int arr[32] = {123};
-> 6 global = arr[0];
7 arr[0] = ext;
8 return 0;
9 }
(lldb) print arr
(int [32]) $0 = {
[0] = 123
[1] = 0
[2] = -1579873760
[3] = 32657
[4] = 32
[and so on...]
Also, in GDB (8.2.1) the elements are printed as <synthetic pointer> instead of
<optimized out>:
(gdb) print arr
$1 = {123, <synthetic pointer> <repeats 31 times>}
It is unclear to me if the producer must cover the whole variable when emitting
composite location descriptions, or if the consumers should be able to handle
that, assuming that parts that are not explicitly covered are implicitly
covered by empty location descriptions. I did not manage to find anything in
the DWARF 4 and 5 standards that mandate the former (but I may of course have
missed it).</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>