[LLVMdev] unwind's permanent residence

[Saleem Abdulrasool]

On Fri, Jan 30, 2015 at 12:43 PM, Jonathan Roelofs <
jonathan at codesourcery.com> wrote:

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


I think that controlling that via a flag is best if we want to continue
using libgcc_s/libgcc_eh instead of libuwnind.


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


I agree with this.


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

Im willing to do the leg work if thats what it takes, however, Id like to
get a clear consensus before proceeding.

So far, it seems that there is no argument against moving it into a
separate repository.  Everyone agrees that this would be conducive to
ensuring that we don't end up with unintended layering violations.  Why
don't we give it a few days to allow others to comment before going with
that solution (hopefully all the particularly interested parties are
already on this thread).


>
> Cheers,
>
> Jon
>
>
>> --
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org
>>
>
> --
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
>



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