[LLVMdev] unwind's permanent residence

[Saleem Abdulrasool]

Although this has been discussed in the past, I think that given a few
conversations, it seems that it unfortunately needs to be brought up again.

There seems to be some disagreement over the ideal location of the unwinder
(libunwind).  Currently, libunwind resides in a subdirectory of libc++abi.
There seems to be some desire from multiple parties that it be moved into
compiler-rt or a separate repository.

Currently, when using compiler-rt as the runtime library (on Linux) we use
libgcc_s and libgcc_eh as the builtins serve as the home for
__gcc_personality_v0.  This error handling personality requires unwinding
support, which these libraries provide.  This dependency can be fulfilled
with libunwind.

The concern that has been raised with adjusting this dependency has been
that libunwind is not guaranteed to be built and installed unless libc++abi
is present.  The suggestion was that if libunwind were part of compiler-rt
or a separate repository, it would be easier to ensure that the required
library would be built and installed.

Personally, I am of the opinion that a separate repository for it does make
some sense as painful as it sounds.  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.  There is a proper specification that it implements and
interface it exposes, so it can be replaced with an alternative
implementation.  At the same time, the unwinder is not really tied to
libc++abi either, though it too has a dependency on it.  Again, the use
here can be replaced with an alternate implementation (and AIUI, the build
system already permits this).

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).

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150130/3c3894a2/attachment.html>