[LLVMdev] unwind's permanent residence

[Nick Kledzik]

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

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

Here is what Apple has:

   http://opensource.apple.com/source/libunwind/libunwind-35.3/testsuite/

If you think these are useful, I can upstream them.   But, they are either generic C++ exception tests (already covered by libc++ tests) or are darwin specific assembly that tests that registers are restored properly.  The latter are good things to test in the unwinder but will need some massaging (and a test harness) to work cross platform.

-Nick


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