[LLVMdev] unwind's permanent residence

[Nico Weber]

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>