[LLVMdev] unwind's permanent residence

[Renato Golin]

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.

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