[LLVMdev] LibUnwind into Compiler-RT?

[Jonathan Roelofs]

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