<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 3, 2015 at 7:07 PM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 30 January 2015 at 20:43, Jonathan Roelofs <<a href="mailto:jonathan@codesourcery.com">jonathan@codesourcery.com</a>> wrote:<br>
> 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>
So, do we have a consensus?<br>
<br>
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>
<br>
My idea for 3.2 is something like --unwinder=libgcc_s / libunwind, or<br>
something like that.<br>
<br>
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>
<br>
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 know I'm in some minority, but whatever ends up happening please be aware that some platforms and targets aren't using the bundled unwind.</div><div><br></div><div>Specifically this non-gnu one (aka HP's libunwind permissively licensed)</div><div><a href="http://www.nongnu.org/libunwind/download.html">www.nongnu.org/libunwind/download.html</a><br></div><div><br></div><div>In my experience when it's used in the compiler the name (libgcc, libeh, libunwind) isn't always the same. (So searching for a particular lib name as the unwinder is fragile)</div><div>----------</div><div>Summary: pretty please allow a cmake option like</div><div>UNWIND_LIB which can be null or something user defined. (I think this is covered in one of the cases above, but just want to be clear)</div><div><br></div><div>Thanks for the minute</div><div><br></div></div></div></div>