[LLVMdev] LibUnwind into Compiler-RT?

[Antoine Labour]

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>