[llvm-bugs] [Bug 38506] After r337339 (addrsig support), clang can emit unnecessary __gxx_personality_v0 references

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=38506

Dimitry Andric <dimitry at andric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #5 from Dimitry Andric <dimitry at andric.com> ---
(In reply to Peter Collingbourne from comment #4)
> 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.

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.


> 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:
> 
> https://github.com/llvm-mirror/libunwind/blob/
> 1e73ceedf467eebae88c3f560c680cee3c527f24/src/CMakeLists.txt#L69

Aha, we've explicitly set -fexceptions even:

https://github.com/freebsd/freebsd/commit/a37322ec29905aeb923e1f080ffb6beb49742151#diff-227f048d83a644d7cb341478d67100f8

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".


> 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?

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!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180810/78f65d2e/attachment.html>