[LLVMdev] unwind's permanent residence

[Renato Golin]

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