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.> +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
The build for the unwinder is already structured such that moving it should be easy enough. I don't really care if it ends up in its own repo or in compiler-rt, but I think either makes more sense than its current residence. One argument for putting it in compiler-rt is that compiler-rt aims to be a replacement for libgcc, and libgcc contains an unwinder. That said, I've always thought it was strange (and downright inconvenient) that libgcc does this, so I think a separate repo might be best. 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?Yes please :) On Fri, Jan 30, 2015 at 1:03 PM, Renato Golin <renato.golin at linaro.org> wrote:> > That's precisely the point. People should use unwinders they want, and > libc++abi should be completely agnostic of which one you use. >Agreed. libc++abi is already built this way, but I don't think I ever moved the same configuration options into libc++. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150130/a39eb127/attachment.html>
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>
On 30 Jan 2015 21:24, "Saleem Abdulrasool" <compnerd at compnerd.org> wrote:> The library is agnostic of the unwinder, the driver is who cares (as itneeds 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. What about the default unwinder for Compiler-RT? Should we assume our own? Gcc's? Assuming nothing will break compilation, since the libraries won't be available... Cheers, Renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150130/5c3dcc06/attachment.html>