<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 30, 2015 at 12:37 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I thought the ARM EHABI added a twist to this because it created some upward dependency from the unwinder to libc++abi.<br>
<br>
Other than that, I don’t have any strong feeling where it lives.<br></blockquote><div><br></div><div>+1 to this. If you don't break the EHABI unwinder while moving things around, I'm happy.</div><div><br></div><div>+Dan, he probably has an opinion on this topic.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-Nick<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Jan 30, 2015, at 12:33 PM, Renato Golin <<a href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>> wrote:<br>
> On 30 January 2015 at 20:17, Saleem Abdulrasool <<a href="mailto:compnerd@compnerd.org">compnerd@compnerd.org</a>> wrote:<br>
>> There is a valid point that the<br>
>> unwinder supports the compiler in some sense (for exception handling).  It<br>
>> seems that its not particularly as intrinsically tied to the compiler as the<br>
>> builtins are.<br>
><br>
> Unwinding is not just used for EH, but also debugging, profiling,<br>
> sanitizers (when in slow-mode) and possibly other code inspection<br>
> tools. While still not strictly for *compiler* support, it is for many<br>
> other toolchain components.<br>
><br>
> The counter argument, that libc++ has other low-level code to deal<br>
> with exception handling so it would make sense to bundle the unwinder<br>
> together, is also compelling. But in my view, less so.<br>
><br>
><br>
>> So, I am bringing up this question once more: what can we do about this<br>
>> concern?  Is moving it to a separate repository acceptable?  Or perhaps<br>
>> moving it to compiler-rt is palatable to more of the involved developers (as<br>
>> much as I may prefer an alternate solution).<br>
><br>
> For my purposes, bundling it in compiler-rt would be the easiest<br>
> solution. It'd also make Clang simpler regarding --rtlib=compiler-rt.<br>
> I'm also assuming that libc++ should be able to work with libgcc_s and<br>
> other unwinding libraries, and, even if our unwinder is local to it,<br>
> it seems very standard in the interface it exports.<br>
><br>
> However, if libc++ folks don't want to depend on compiler-rt or<br>
> libgcc_s for their own unwinding, I don't see a problem in having it<br>
> in a separate repository under the LLVM server. One less, one more,<br>
> won't make a difference for developers and build systems.<br>
><br>
> What I don't agree is to leave it as it is, so that even to compile C<br>
> code in debug/profile mode, I need to either include libgcc_s or<br>
> libc++abi.<br>
><br>
> cheers,<br>
> --renato<br>
<br>
</div></div></blockquote></div><br></div></div>