[LLVMdev] unwind's permanent residence

[Jonathan Roelofs]

On 1/30/15 1:17 PM, Saleem Abdulrasool wrote:
> 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.

I think this dependence should be satisfied by the target system's 
unwinder, whatever that is. If folks want to use this libunwind for 
their platform, that's fine... but we should probably continue to use 
libgcc_s and libgcc_eh on linux when that's the platform's unwinder.

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

+1 for putting it in a separate repo. Separate repos helps keep layering 
nonsense to a minimum.

It would be nice if we had some libunwind-specific tests too. Currently 
we have none, other than the c++ abi tests.  Nick, does Apple have any 
they're willing to upstream?

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

The fact that this ARM EHABI-induced layering violation is here 
shouldn't stop us from separating them.

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

Last time we brought this up, there was only partial consensus, and then 
someone arbitrarily declared total consensus (without compelling 
arguments in any particular direction) that we were going to move it to 
compiler_rt. Then the discussion fell on the floor because no-one had 
time to actually do the move. Please, let's not let that happen again 
this time.


Cheers,

Jon
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded