I thought the ARM EHABI added a twist to this because it created some upward dependency from the unwinder to libc++abi. Other than that, I don’t have any strong feeling where it lives. -Nick On Jan 30, 2015, at 12:33 PM, Renato Golin <renato.golin at linaro.org> wrote:> On 30 January 2015 at 20:17, Saleem Abdulrasool <compnerd at compnerd.org> wrote: >> There is a valid point that the >> unwinder supports the compiler in some sense (for exception handling). It >> seems that its not particularly as intrinsically tied to the compiler as the >> builtins are. > > Unwinding is not just used for EH, but also debugging, profiling, > sanitizers (when in slow-mode) and possibly other code inspection > tools. While still not strictly for *compiler* support, it is for many > other toolchain components. > > The counter argument, that libc++ has other low-level code to deal > with exception handling so it would make sense to bundle the unwinder > together, is also compelling. But in my view, less so. > > >> So, I am bringing up this question once more: what can we do about this >> concern? Is moving it to a separate repository acceptable? Or perhaps >> moving it to compiler-rt is palatable to more of the involved developers (as >> much as I may prefer an alternate solution). > > For my purposes, bundling it in compiler-rt would be the easiest > solution. It'd also make Clang simpler regarding --rtlib=compiler-rt. > I'm also assuming that libc++ should be able to work with libgcc_s and > other unwinding libraries, and, even if our unwinder is local to it, > it seems very standard in the interface it exports. > > However, if libc++ folks don't want to depend on compiler-rt or > libgcc_s for their own unwinding, I don't see a problem in having it > in a separate repository under the LLVM server. One less, one more, > won't make a difference for developers and build systems. > > What I don't agree is to leave it as it is, so that even to compile C > code in debug/profile mode, I need to either include libgcc_s or > libc++abi. > > cheers, > --renato
On Fri, Jan 30, 2015 at 12:37 PM, Nick Kledzik <kledzik at apple.com> wrote:> I thought the ARM EHABI added a twist to this because it created some > upward dependency from the unwinder to libc++abi. > > Other than that, I don’t have any strong feeling where it lives. >+1 to this. If you don't break the EHABI unwinder while moving things around, I'm happy. +Dan, he probably has an opinion on this topic.> > -Nick > > On Jan 30, 2015, at 12:33 PM, Renato Golin <renato.golin at linaro.org> > wrote: > > On 30 January 2015 at 20:17, Saleem Abdulrasool <compnerd at compnerd.org> > wrote: > >> There is a valid point that the > >> unwinder supports the compiler in some sense (for exception handling). > It > >> seems that its not particularly as intrinsically tied to the compiler > as the > >> builtins are. > > > > Unwinding is not just used for EH, but also debugging, profiling, > > sanitizers (when in slow-mode) and possibly other code inspection > > tools. While still not strictly for *compiler* support, it is for many > > other toolchain components. > > > > The counter argument, that libc++ has other low-level code to deal > > with exception handling so it would make sense to bundle the unwinder > > together, is also compelling. But in my view, less so. > > > > > >> So, I am bringing up this question once more: what can we do about this > >> concern? Is moving it to a separate repository acceptable? Or perhaps > >> moving it to compiler-rt is palatable to more of the involved > developers (as > >> much as I may prefer an alternate solution). > > > > For my purposes, bundling it in compiler-rt would be the easiest > > solution. It'd also make Clang simpler regarding --rtlib=compiler-rt. > > I'm also assuming that libc++ should be able to work with libgcc_s and > > other unwinding libraries, and, even if our unwinder is local to it, > > it seems very standard in the interface it exports. > > > > However, if libc++ folks don't want to depend on compiler-rt or > > libgcc_s for their own unwinding, I don't see a problem in having it > > in a separate repository under the LLVM server. One less, one more, > > won't make a difference for developers and build systems. > > > > What I don't agree is to leave it as it is, so that even to compile C > > code in debug/profile mode, I need to either include libgcc_s or > > libc++abi. > > > > cheers, > > --renato > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150130/f5ee2b3c/attachment.html>
On 1/30/15 2:03 PM, Nico Weber wrote:> On Fri, Jan 30, 2015 at 12:37 PM, Nick Kledzik <kledzik at apple.com > <mailto:kledzik at apple.com>> wrote: > > I thought the ARM EHABI added a twist to this because it created > some upward dependency from the unwinder to libc++abi.ARM EHABI does have this upward dependency on the private type-infos for matching catch descriptors. Our implementation of EHABI doesn't really implement this part of the spec (See ARM EHABI, section #9.2 [1]). IIRC, we get away with that because clang/llvm doesn't code that needs them. (yet?) Jon> > Other than that, I don’t have any strong feeling where it lives. > > > +1 to this. If you don't break the EHABI unwinder while moving things > around, I'm happy. > > +Dan, he probably has an opinion on this topic. > > > -Nick[1]: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf -- Jon Roelofs jonathan at codesourcery.com CodeSourcery / Mentor Embedded