<div dir="ltr">On Tue, Feb 3, 2015 at 4:07 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</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="">On 30 January 2015 at 20:43, Jonathan Roelofs <<a href="mailto:jonathan@codesourcery.com">jonathan@codesourcery.com</a>> wrote:<br>
</span><span class="">> Last time we brought this up, there was only partial consensus, and then<br>
> someone arbitrarily declared total consensus (without compelling arguments<br>
> in any particular direction) that we were going to move it to compiler_rt.<br>
> Then the discussion fell on the floor because no-one had time to actually do<br>
> the move. Please, let's not let that happen again this time.<br>
<br>
</span>So, do we have a consensus?<br></blockquote><div><br></div><div>I think so.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
AFAICS, the most agree solution (with optionals to be defined):<br>
<br>
1. Move Unwinder to its own repository in the LLVM server<br>
2. Make the CMake connections from libc++abi and compiler-rt<br>
  2.1 OPTIONAL 1: err if libunwinder is not there, clang errs if rtlib=RT<br>
  2.2 OPTIONAL 2: warns if libunwind is not there, clang errs if rtlib=RT<br>
  2.3 OPTIONAL 3: nothing, make clang smarter to pick existing unwinder<br>
3. Change clang to assume -lunwind when --rtlib=compiler-rt<br>
  3.1 OPTIONAL 4: allow linker error if no -lunwind / -lgcc_s<br>
  3.2 OPTIONAL 5: Add option to change unwinder library by not adding<br>
-lunwind/-lgcc_s, but whatever comes as argument<br>
<br>
1, 2, and 3 must be changed.<br>
<br>
I vote for adding { 2.2, 3.1 } for now, { 2.2, 3.1, 3.2 } for later.<br></blockquote><div><br></div><div>It seems that there is some interest in making the unwinder a build time option, so that should be as good as 2.2 right?  I am definitely fine with 3.1 (its no better or worse from the status quo).</div><div><br></div><div>I would like say that although Im not a fan of options 2.1 and 2.2, I do think that 2.3 is a bad idea.  There is far too much complexity involved, and worse yet, it needs a number of knobs to get right -- what if I have gcc 4.7, 4.8, 4.9 (each has its own libgcc_s), how do you select one?  What if the layout differs between Linux distributions?  There is just too much variability.  Trying to reuse part of another compiler's resources is just too brittle IMO, and Id rather not introduce more of that behavior into clang.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My idea for 3.2 is something like --unwinder=libgcc_s / libunwind, or<br>
something like that.<br></blockquote><div><br></div><div>Thats fine; it is effectively what I was suggesting that we do if people feel strongly that we need to support clang_rt + gcc_s.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I personally don't think the front-end scanning existing libraries is<br>
a good thing to do, but I'm not against the idea, if anyone feels<br>
strongly about it.<br></blockquote><div><br></div><div>Strongly agreed.  This can easily change subtly and diverge in behavior from the linker.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If all of us could agree to a common solution, and make sure all<br>
interested parties are in, we should do the move before 3.7.<br></blockquote><div><br></div><div>I was hoping to do this much sooner (in the next few days) for the 3.7 release :-).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Please, cast your votes.<br>
<br>
cheers,<br>
--renato<br>
</blockquote></div><br>-- <br><div class="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</div></div>