<div dir="ltr">On Fri, Jan 30, 2015 at 12:43 PM, Jonathan Roelofs <span dir="ltr"><<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 1/30/15 1:17 PM, Saleem Abdulrasool wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Although this has been discussed in the past, I think that given a few<br>
conversations, it seems that it unfortunately needs to be brought up again.<br>
<br>
There seems to be some disagreement over the ideal location of the<br>
unwinder (libunwind). Currently, libunwind resides in a subdirectory of<br>
libc++abi. There seems to be some desire from multiple parties that it<br>
be moved into compiler-rt or a separate repository.<br>
<br>
Currently, when using compiler-rt as the runtime library (on Linux) we<br>
use libgcc_s and libgcc_eh as the builtins serve as the home for<br>
__gcc_personality_v0. This error handling personality requires<br>
unwinding support, which these libraries provide. This dependency can<br>
be fulfilled with libunwind.<br>
</blockquote>
<br></span>
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.</blockquote><div><br></div><div>I think that controlling that via a flag is best if we want to continue using libgcc_s/libgcc_eh instead of libuwnind.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The concern that has been raised with adjusting this dependency has been<br>
that libunwind is not guaranteed to be built and installed unless<br>
libc++abi is present. The suggestion was that if libunwind were part of<br>
compiler-rt or a separate repository, it would be easier to ensure that<br>
the required library would be built and installed.<br>
</blockquote>
<br></span>
+1 for putting it in a separate repo. Separate repos helps keep layering nonsense to a minimum.<br>
<br>
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?<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Personally, I am of the opinion that a separate repository for it does<br>
make some sense as painful as it sounds. There is a valid point that<br>
the unwinder supports the compiler in some sense (for exception<br>
handling). It seems that its not particularly as intrinsically tied to<br>
the compiler as the builtins are. There is a proper specification that<br>
it implements and interface it exposes, so it can be replaced with an<br>
alternative implementation. At the same time, the unwinder is not<br>
really tied to libc++abi either, though it too has a dependency on it.<br>
</blockquote>
<br></span>
The fact that this ARM EHABI-induced layering violation is here shouldn't stop us from separating them.</blockquote><div><br></div><div>I agree with this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Again, the use here can be replaced with an alternate implementation<br>
(and AIUI, the build system already permits this).<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<br>
(as much as I may prefer an alternate solution).<br>
</blockquote>
<br></span>
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.<br></blockquote><div><br></div><div>Im willing to do the leg work if thats what it takes, however, Id like to get a clear consensus before proceeding.</div><div><br></div><div>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
<br>
Jon<div class="HOEnZb"><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--<br>
Saleem Abdulrasool<br>
compnerd (at) compnerd (dot) org<br>
</blockquote>
<br></div></div><span class="HOEnZb"><font color="#888888">
-- <br>
Jon Roelofs<br>
<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a><br>
CodeSourcery / Mentor Embedded<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</div></div>