So, I remember we discussed this earlier this year, but I can't find the thread. The idea is to move libunwind into compiler-rt for the simple reasons below: 1. Unwinding is not exclusive to C++, nor exception handling. 2. Clang still includes libgcc_s and libgcc_eh when using compiler-rt (maybe eh isn't needed, but it was there for libgcc). 3. Testing the libunwind with libc++ on ARM is not possible, because libgcc_s merges RT abi with unwind, duplicating the implementation of some, but not all, unwind functions. I'm not sure how the move would take place, but I remember most people being in favour, so I'm expecting that someone already has a plan. :) I'm guessing that the libgcc_eh EH functions are implemented in libc++, while the libgcc_s unwind is in libc++abi. If not, we might have a hard time linking them together independently. We'd have to be sure to move the tests as well, which could be the hardest part, since all libc++ unwind-depending tests would have to either be moved or rely on implicit dependencies. An alternative to fix the libc++ tests on ARM would be to require Compiler-RT to be there as well, but, as I said, Clang links gcc_eh and gcc_s when you choose --rtlib=compiler-rt, making the exercise moot. Or we could just say that libc++ *needs* compiler-RT and call it a day. Ideas? cheers, --renato
I remember there being a ARM EHABI reason why this won't work, but I don't remember the specifics. IIRC, had something to do with how c++ rtti is required to be handled by the catch handlers, and would mean layering problems if we moved it. Antoine, do you remember the specifics? On 10/22/14 11:39 AM, Renato Golin wrote:> So, I remember we discussed this earlier this year, but I can't find the thread. > > The idea is to move libunwind into compiler-rt for the simple reasons below: > > 1. Unwinding is not exclusive to C++, nor exception handling. > 2. Clang still includes libgcc_s and libgcc_eh when using compiler-rt > (maybe eh isn't needed, but it was there for libgcc). > 3. Testing the libunwind with libc++ on ARM is not possible, because > libgcc_s merges RT abi with unwind, duplicating the implementation of > some, but not all, unwind functions.I do compiler_rt + libc++abi + libc++ + clang (with a custom ToolChain) testing of libc++ on bare-metal ARM.... so it is possible. Perhaps you mean to say that it's not possible to test libunwind on arm-linux when using compiler_rt?> > I'm not sure how the move would take place, but I remember most people > being in favour, so I'm expecting that someone already has a plan. :) > > I'm guessing that the libgcc_eh EH functions are implemented in > libc++, while the libgcc_s unwind is in libc++abi. If not, we might > have a hard time linking them together independently. > > We'd have to be sure to move the tests as well, which could be the > hardest part, since all libc++ unwind-depending tests would have to > either be moved or rely on implicit dependencies. > > An alternative to fix the libc++ tests on ARM would be to require > Compiler-RT to be there as well, but, as I said, Clang links gcc_eh > and gcc_s when you choose --rtlib=compiler-rt, making the exercise > moot.Clang's code isn't frozen... ;)> > Or we could just say that libc++ *needs* compiler-RT and call it a day.This makes me uncomfortable (which I gather is what you're going for) in that not saying so, and maintaining compatibility to build with libgcc as the rtlib keeps us honest. Cheers, Jon> > Ideas? > > cheers, > --renato >-- Jon Roelofs jonathan at codesourcery.com CodeSourcery / Mentor Embedded
On 22 October 2014 19:24, Jonathan Roelofs <jonathan at codesourcery.com> wrote:> I do compiler_rt + libc++abi + libc++ + clang (with a custom ToolChain) testing > of libc++ on bare-metal ARM.... so it is possible. Perhaps you mean to say that > it's not possible to test libunwind on arm-linux when using compiler_rt?Yeah, it's hard and clumsy, not impossible. Basically, I want to avoid requiring people to link against libunwind+rt+libcxxabi if all they need is libcxx or rt.>> An alternative to fix the libc++ tests on ARM would be to require >> Compiler-RT to be there as well, but, as I said, Clang links gcc_eh >> and gcc_s when you choose --rtlib=compiler-rt, making the exercise >> moot. > Clang's code isn't frozen... ;)I know, I put it there. :) I did it because that was what libgcc required, and I didn't want to make compiler-RT depend on libc++, at least not at a Clang level. Since gcc_s and gcc_eh are both provided by libgcc, it makes sense in the GNU case. Maybe, a better approach would be to warn users if they choose compiler-rt (via --rtlib=compiler-rt) and not libunwind or libgcc_s variants. The other problem is symbol clashing. If we start including multiple libraries that implement and export the same symbols, we'll be in trouble soon enough. This already happens with --rtlib=compiler-rt and will happen if I include -lgcc_s on libc++abi tests on ARM (for the RTABI part). Having libunwind on its own repository is also not a horrible idea, but I don't know the logistics of that.>> Or we could just say that libc++ *needs* compiler-RT and call it a day. > This makes me uncomfortable (which I gather is what you're going for) in that > not saying so, and maintaining compatibility to build with libgcc as the rtlib > keeps us honest.Me too, but I have to say it's by far the easiest option. We only have that kind of problem because we split the symbols in a way that is different than GNU tools, so that we'll always have clashes when we try to interoperate. The other easy option is to split in the *exact* same way as libgcc, so that we can mix and match, but that's not free of problems, either. Someone with more knowledge in linkers can chime in on how the symbols are dropped, so that at least we can be sure of which library overrides which. cheers, --renato
On Wed, Oct 22, 2014 at 11:24 AM, Jonathan Roelofs < jonathan at codesourcery.com> wrote:> I remember there being a ARM EHABI reason why this won't work, but I don't > remember the specifics. IIRC, had something to do with how c++ rtti is > required > to be handled by the catch handlers, and would mean layering problems if we > moved it. Antoine, do you remember the specifics? >For a complete implementation, the arm-defined PRs (__aeabi_unwind_cpp_pr[0-2]) need to call the functions in 8.4.2 in phase 2, which are in libc++abi. In particular, as you mention, __cxa_type_match needs the rtti info. That said, currently this part is not implemented in libunwind, among others because clang never generates code that uses arm-defined PRs for exceptions and cleanup, only for trivial frame unwinding (it always uses __gxx_personality_v0 for exceptions/cleanup), so I don't think today libunwind depends on libc++abi, except for the recent patch for _Unwind_Backtrace. Antoine> > On 10/22/14 11:39 AM, Renato Golin wrote: > > So, I remember we discussed this earlier this year, but I can't find the > thread. > > > > The idea is to move libunwind into compiler-rt for the simple reasons > below: > > > > 1. Unwinding is not exclusive to C++, nor exception handling. > > 2. Clang still includes libgcc_s and libgcc_eh when using compiler-rt > > (maybe eh isn't needed, but it was there for libgcc). > > 3. Testing the libunwind with libc++ on ARM is not possible, because > > libgcc_s merges RT abi with unwind, duplicating the implementation of > > some, but not all, unwind functions. > I do compiler_rt + libc++abi + libc++ + clang (with a custom ToolChain) > testing > of libc++ on bare-metal ARM.... so it is possible. Perhaps you mean to say > that > it's not possible to test libunwind on arm-linux when using compiler_rt? > > > > I'm not sure how the move would take place, but I remember most people > > being in favour, so I'm expecting that someone already has a plan. :) > > > > I'm guessing that the libgcc_eh EH functions are implemented in > > libc++, while the libgcc_s unwind is in libc++abi. If not, we might > > have a hard time linking them together independently. > > > > We'd have to be sure to move the tests as well, which could be the > > hardest part, since all libc++ unwind-depending tests would have to > > either be moved or rely on implicit dependencies. > > > > An alternative to fix the libc++ tests on ARM would be to require > > Compiler-RT to be there as well, but, as I said, Clang links gcc_eh > > and gcc_s when you choose --rtlib=compiler-rt, making the exercise > > moot. > Clang's code isn't frozen... ;) > > > > > Or we could just say that libc++ *needs* compiler-RT and call it a day. > This makes me uncomfortable (which I gather is what you're going for) in > that > not saying so, and maintaining compatibility to build with libgcc as the > rtlib > keeps us honest. > > > Cheers, > > Jon > > > > Ideas? > > > > cheers, > > --renato > > > > -- > Jon Roelofs > jonathan at codesourcery.com > CodeSourcery / Mentor Embedded >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141022/c55ff097/attachment.html>