<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 - Debug info needs correct symbol ranges"
href="https://bugs.llvm.org/show_bug.cgi?id=49274">49274</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Debug info needs correct symbol ranges
</td>
</tr>
<tr>
<th>Product</th>
<td>lld
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</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>MachO
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>jezreel@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>gkm@fb.com, jezreel@gmail.com, llvm-bugs@lists.llvm.org, smeenai@fb.com
</td>
</tr></table>
<p>
<div>
<pre>The N_FUN entries in our STABS debug info require us to emit where functions
start and end. Right now we don't have accurate information on where a function
symbol ends. As <a href="https://reviews.llvm.org/D89257">https://reviews.llvm.org/D89257</a> says:
<span class="quote">> Additionally, this current implementation doesn't accurately reflect the size</span >
of function symbols. It uses the size of their containing sections as a proxy,
but that is only accurate if .subsections_with_symbols is set, and if there
isn't an N_ALT_ENTRY in that particular subsection.
I am not sure how ld64 handles this. I initially suspected we should sort the
symbols in our InputFiles by address order, and use the start of the next
symbol to determine the end of the current one. But I'm wondering if perhaps we
should use the compact unwind info generated by `.cfi_endproc` instead. (`xcrun
unwinddump` does show that the unwind info contains information about function
size.) Let's figure out what ld64 is doing...
If we do end up sorting the list in input symbols, we should rewrite
`ObjFile::parseSymbols` to take advantage of it (as a follow-up task). Right
now that method splits up sections so that each one coincides with the start of
a symbol. It does this assuming that the list of symbols is unsorted, and could
likely be made faster if we had pre-sorted the list.</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>