[LLVMdev] unwind's permanent residence

[Saleem Abdulrasool]

On Fri, Jan 30, 2015 at 1:03 PM, Renato Golin <renato.golin at linaro.org>
wrote:

> On 30 January 2015 at 20:43, Jonathan Roelofs <jonathan at codesourcery.com>
> wrote:
> > 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.
>
> That's precisely the point. People should use unwinders they want, and
> libc++abi should be completely agnostic of which one you use.


The library is agnostic of the unwinder, the driver is who cares (as it
needs to generate the linker invocation).  I think that adding a flag to
control that similar to -rtlib is probably what we may have to do then.


>
>
> > +1 for putting it in a separate repo. Separate repos helps keep layering
> > nonsense to a minimum.
> >
> > 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?
>
> +1
>
>
> > 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.
>
> Well, people that didn't mind it in compiler-rt were the last ones to
> drop the thread, so it "seemed" like we forced a consensus, but there
> really wasn't one. At least, I wasn't convinced, but wasn't bothered
> either. Moving to its own repo is also a good solution.
>
> 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/20150130/43a06149/attachment.html>