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. On Fri, Jan 30, 2015 at 5:30 PM, Saleem Abdulrasool <compnerd at compnerd.org> wrote:> On Fri, Jan 30, 2015 at 4:15 PM, Dan Albert <danalbert at google.com> wrote: > >> On Fri, Jan 30, 2015 at 4:12 PM, Saleem Abdulrasool < >> compnerd at compnerd.org> wrote: >> >>> On Fri, Jan 30, 2015 at 3:35 PM, Dan Albert <danalbert at google.com> >>> wrote: >>> >>>> Shouldn't it just use the default unwinder for the given platform? >>>> >>> >>> Sure, but what is the default unwinder for a given platform? >>> >>> Lets go with Linux. I have two different images (okay, I have one, but >>> Im sufficiently familiar with Gentoo as well): >>> - Gentoo w/ GCC >>> - exherbo w/o GCC >>> >>> Both are Linux. Whats the default unwinder? >>> >> >> From a triple standpoint, aren't targets marked as linux-gnu? That should >> be enough to determine that, right? >> > > Yeah, both are linux-gnu. How do you differentiate between libunwind vs > libgcc (-static-libgcc) or libgcc_s between the two? What about when you > are cross-compiling, so, host != target, and therefore cannot use > /etc/*-release? > > -- > Saleem Abdulrasool > compnerd (at) compnerd (dot) org >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150130/e4fb6026/attachment.html>
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.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). David
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