<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-dwarfdump cannot handle .debug_ranges/.debug_loc empty relocated range in ET_REL object"
href="https://bugs.llvm.org/show_bug.cgi?id=46804">46804</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>llvm-dwarfdump cannot handle .debug_ranges/.debug_loc empty relocated range in ET_REL object
</td>
</tr>
<tr>
<th>Product</th>
<td>tools
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Windows NT
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>llvm-dwarfdump
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>jh7370.2008@my.bristol.ac.uk
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>See <a href="http://lists.llvm.org/pipermail/llvm-dev/2020-July/143575.html">http://lists.llvm.org/pipermail/llvm-dev/2020-July/143575.html</a> for full
context.
A .debug_ranges/.debug_loc sequence ends with an entry containing 0 for the two
addresses. In a fully-linked object, llvm-dwarfdump handles this fine. However,
in an ET_REL file, there might be relocations patching an apparent 0, 0 entry.
The parsing code does resolve relocations before determining if an address is
zero. However, if the relocations happen to be section-relative (or
symbol-relative, where the symbol is at a section start), the resultant address
will be the relocation addend, which could be 0 in both cases.
Simple example:
.section .foo,"a",@progbits
nop
.section .debug_ranges,"",@progbits:
.quad foo
.quad foo
.quad 0, 0 # actual terminator
This is a particular problem in .debug_loc, where the entry might have some
data afterwards, so a premature termination will cause parsing to completely
fail.
The solution is to not treat an address patched by a relocation as 0, for the
purpose of termination.</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>