<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:dimitry@andric.com" title="Dimitry Andric <dimitry@andric.com>"> <span class="fn">Dimitry Andric</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - After r337339 (addrsig support), clang can emit unnecessary __gxx_personality_v0 references"
href="https://bugs.llvm.org/show_bug.cgi?id=38506">bug 38506</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>NEW
</td>
<td>RESOLVED
</td>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>INVALID
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - After r337339 (addrsig support), clang can emit unnecessary __gxx_personality_v0 references"
href="https://bugs.llvm.org/show_bug.cgi?id=38506#c5">Comment # 5</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - After r337339 (addrsig support), clang can emit unnecessary __gxx_personality_v0 references"
href="https://bugs.llvm.org/show_bug.cgi?id=38506">bug 38506</a>
from <span class="vcard"><a class="email" href="mailto:dimitry@andric.com" title="Dimitry Andric <dimitry@andric.com>"> <span class="fn">Dimitry Andric</span></a>
</span></b>
<pre>(In reply to Peter Collingbourne from <a href="show_bug.cgi?id=38506#c4">comment #4</a>)
<span class="quote">> Thanks, I was able to reproduce.
>
> Looking more closely, it seems like this translation unit is relying on an
> optimization to remove the reference to the personality function. If I
> compile it at -O0 I see an invoke instruction, which gets compiled into
> unwind info containing a reference to the personality function.</span >
Indeed, I see this too, even with our regular libgcc_s build (which uses
libunwind). At -O0, even clang 6.0.0 puts in a reference to the personality
function.
<span class="quote">> That led me to wonder whether you're compiling libunwind correctly, since I
> would be surprised if libunwind could not be correctly compiled at -O0. The
> libunwind build system uses -fno-exceptions -funwind-tables by default, and
> there is a rule to prevent libunwind from being built as a .so if exceptions
> are enabled, perhaps for exactly this reason:
>
> <a href="https://github.com/llvm-mirror/libunwind/blob/">https://github.com/llvm-mirror/libunwind/blob/</a>
> 1e73ceedf467eebae88c3f560c680cee3c527f24/src/CMakeLists.txt#L69</span >
Aha, we've explicitly set -fexceptions even:
<a href="https://github.com/freebsd/freebsd/commit/a37322ec29905aeb923e1f080ffb6beb49742151#diff-227f048d83a644d7cb341478d67100f8">https://github.com/freebsd/freebsd/commit/a37322ec29905aeb923e1f080ffb6beb49742151#diff-227f048d83a644d7cb341478d67100f8</a>
The stated reason being "When an exception is thrown the unwinder must unwind
its own C source
(starting with _Unwind_RaiseException in UnwindLevel1.c), so it needs to
be built with unwinding data".
<span class="quote">> And indeed, if I compile libunwind locally using its build system I don't
> see references to the personality function, even with clang trunk. Are you
> also compiling libunwind with -fno-exceptions -funwind-tables?</span >
Indeed not, because of that explicit commit. I'll now go fix that on the
FreeBSD side, this bug can be closed.
Thanks for your help!</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>