[LLVMdev] unwind's permanent residence

[Saleem Abdulrasool]

On Tue, Feb 3, 2015 at 4:07 AM, Renato Golin <renato.golin at linaro.org>
wrote:

> On 30 January 2015 at 20:43, Jonathan Roelofs <jonathan at codesourcery.com>
> wrote:
> > 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.
>
> So, do we have a consensus?
>

I think so.


> AFAICS, the most agree solution (with optionals to be defined):
>
> 1. Move Unwinder to its own repository in the LLVM server
> 2. Make the CMake connections from libc++abi and compiler-rt
>   2.1 OPTIONAL 1: err if libunwinder is not there, clang errs if rtlib=RT
>   2.2 OPTIONAL 2: warns if libunwind is not there, clang errs if rtlib=RT
>   2.3 OPTIONAL 3: nothing, make clang smarter to pick existing unwinder
> 3. Change clang to assume -lunwind when --rtlib=compiler-rt
>   3.1 OPTIONAL 4: allow linker error if no -lunwind / -lgcc_s
>   3.2 OPTIONAL 5: Add option to change unwinder library by not adding
> -lunwind/-lgcc_s, but whatever comes as argument
>
> 1, 2, and 3 must be changed.
>
> I vote for adding { 2.2, 3.1 } for now, { 2.2, 3.1, 3.2 } for later.
>

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

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.


> My idea for 3.2 is something like --unwinder=libgcc_s / libunwind, or
> something like that.
>

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.


> I personally don't think the front-end scanning existing libraries is
> a good thing to do, but I'm not against the idea, if anyone feels
> strongly about it.
>

Strongly agreed.  This can easily change subtly and diverge in behavior
from the linker.


> If all of us could agree to a common solution, and make sure all
> interested parties are in, we should do the move before 3.7.
>

I was hoping to do this much sooner (in the next few days) for the 3.7
release :-).


> Please, cast your votes.
>
> cheers,
> --renato
>

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150203/3a546a83/attachment.html>