<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 - lld does not clean up __eh_frame section after creating __unwind_info"
href="https://bugs.llvm.org/show_bug.cgi?id=50410">50410</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>lld does not clean up __eh_frame section after creating __unwind_info
</td>
</tr>
<tr>
<th>Product</th>
<td>lld
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</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>MachO
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>nicolasweber@gmx.de
</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>Repro:
1. Download
<a href="https://drive.google.com/file/d/1j6_f55jX1WYjwrDSmQYbr_X043mLG9L2/view?usp=sharing">https://drive.google.com/file/d/1j6_f55jX1WYjwrDSmQYbr_X043mLG9L2/view?usp=sharing</a>
2. Unpack, cd chromium_framework
3. Remove `-dead_strip` from response.txt
4. `ld @response.txt`
5. `otool -l Chromium.app/Contents/Frameworks/Chromium\
Framework.framework/Chromium\ Framework | grep -A10 eh_frame | grep size`
=> size 0x00000000000ad310
6. `ld64.lld @response.txt`, same otool
=> size 0x0000000002859c88
That's 0.676 MiB with ld vs 40.35 MiB with lld. The lld-linked
'Chromium.app/Contents/Frameworks/Chromium
Framework.framework/Versions/Current/Chromium Framework' is 55M larger, so this
is responsible for 72% of the bigger size.
(There's a "prune __eh_frame entries superseded by __unwind_info" TODO in
UnwindInfoSection.cpp for this.)
---
Does anyone know why clang writes __eh_frame in addition to compact unwind?
Having the compiler write it only to have the linker remove it again seems a
bit roundabout. There's a OmitDwarfIfHaveCompactUnwind in
llvm/lib/MC/MCObjectFileInfo.cpp that seems to control that, but it's set to
true only for watchOS, so it does seem intentional. I don't yet understand why
though.
(We should fix it in lld anyways, but maybe we could fix it in the compiler as
well -- but I guess there's some reason against the latter that I don't see
yet.</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>