[LLVMdev] unwind's permanent residence

[Jonathan Roelofs]

On 1/31/15 5:36 AM, Renato Golin wrote:
> On 31 Jan 2015, at 03:02, Dan Albert <danalbert at google.com> wrote:
>> Talked it over with Saleem on IRC, and I've come around to thinking libunwind is a better default for --rtlib=compiler-rt. Reason being that --rtlib=compiler-rt means libgcc probably isn't even available.
>
> It's not just that, it's about making it self-contained. In a system
> with both gcc and llvm libraries, with a package structure, you have
> to depend on other packages. If I was to build a compiler-rt package,
> I'd have to either include libunwind in it or create another package
> for that and mark it as dependency for RT.
>
> Since we do provide an unwinder, there is no point in making
> compiler-rt depend on libgcc just because it provides libgcc_s. It's
> the same as making libc++ depend on stdlibc++ because of some missing
> components that we already ship on a different package.
>
>
> On 31 January 2015 at 07:43, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
>> On FreeBSD, we install compiler-rt as libgcc (or, at least, symlink it to libgcc).  This means that all compilers can find it and we don't have issues when a gcc-compiled program loads a clang-compiled library (or vice versa).
>
> This is the other end of the spectrum, where there is no gcc at all.
> This is somewhat easier, since there is no cross-linking.
>
> My worry of using libunwind by default on a libgcc-system is that
> people will start finding a lot of interoperating trouble when they
> dynamically link a gcc-compiled library which throws an exception and
> you catch on your code. However, that kind of interoperation is
> assumed to be correct, so we will have to cope with that anyway.
My worry is the scenario of throwing in one dso, then running a cleanup 
as you're unwinding through another dso. If that cleanup throws, and 
invokes a different unwinder, there's no way for that second unwinder to 
know about the state of the first. If this were c++, we'd break the 
requirement that throwing from a destructor during exception propagation 
causes the app to terminate.

I think there can really only be one unwinder per application.


Jon
>
> All in all, making it the default, at least on the master branch, will
> expose those kind of problems earlier, so we can fix them before
> shipping any stable compiler.
>
> If, during release 3.7, there are still too many bugs, we can revert
> the patch on branch release_37, so to have another six months to fix
> them, and so on.
>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded