[LLVMdev] LibUnwind into Compiler-RT? (original) (raw)

Jonathan Roelofs jonathan at codesourcery.com
Wed Oct 22 11:24:42 PDT 2014

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 libgccs and libgcceh 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 libgccs 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 libgcceh EH functions are implemented in libc++, while the libgccs 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 gcceh and gccs 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

More information about the llvm-dev mailing list