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
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
On Jan 31, 2015 08:42, "Jonathan Roelofs" <jroelofs.lists at gmail.com> wrote:> My worry is the scenario of throwing in one dso, then running a cleanupas 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.This was my concern as well, but we are only talking about the default behavior of --rtlib=compiler-rt, which is a case where we have no extra information. For triples that we know for a fact use libgcc as the system unwinder it would make sense to have that target's default be libgcc. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150131/e6873212/attachment.html>
On 31 January 2015 at 16:39, Jonathan Roelofs <jroelofs.lists at gmail.com> wrote:> 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 invokesa> 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.In theory, the Itanium ABI doesn't require that any implementation cooperates with any other, but in practice, libunwinder lives in a world where GNU is the law. If we want to migrate one application at a time, we'll have to interoperate. Not sure how, though... Cheers, Renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150131/1665091e/attachment.html>