<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 22, 2014 at 11:24 AM, Jonathan Roelofs <span dir="ltr"><<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I remember there being a ARM EHABI reason why this won't work, but I don't<br>
remember the specifics. IIRC, had something to do with how c++ rtti is required<br>
to be handled by the catch handlers, and would mean layering problems if we<br>
moved it. Antoine, do you remember the specifics?<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>Antoine</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
On 10/22/14 11:39 AM, Renato Golin wrote:<br>
> So, I remember we discussed this earlier this year, but I can't find the thread.<br>
><br>
> The idea is to move libunwind into compiler-rt for the simple reasons below:<br>
><br>
> 1. Unwinding is not exclusive to C++, nor exception handling.<br>
> 2. Clang still includes libgcc_s and libgcc_eh when using compiler-rt<br>
> (maybe eh isn't needed, but it was there for libgcc).<br>
> 3. Testing the libunwind with libc++ on ARM is not possible, because<br>
> libgcc_s merges RT abi with unwind, duplicating the implementation of<br>
> some, but not all, unwind functions.<br>
I do compiler_rt + libc++abi + libc++ + clang (with a custom ToolChain) testing<br>
of libc++ on bare-metal ARM.... so it is possible. Perhaps you mean to say that<br>
it's not possible to test libunwind on arm-linux when using compiler_rt?<br>
><br>
> I'm not sure how the move would take place, but I remember most people<br>
> being in favour, so I'm expecting that someone already has a plan. :)<br>
><br>
> I'm guessing that the libgcc_eh EH functions are implemented in<br>
> libc++, while the libgcc_s unwind is in libc++abi. If not, we might<br>
> have a hard time linking them together independently.<br>
><br>
> We'd have to be sure to move the tests as well, which could be the<br>
> hardest part, since all libc++ unwind-depending tests would have to<br>
> either be moved or rely on implicit dependencies.<br>
><br>
> An alternative to fix the libc++ tests on ARM would be to require<br>
> Compiler-RT to be there as well, but, as I said, Clang links gcc_eh<br>
> and gcc_s when you choose --rtlib=compiler-rt, making the exercise<br>
> moot.<br>
Clang's code isn't frozen... ;)<br>
<br>
><br>
> Or we could just say that libc++ *needs* compiler-RT and call it a day.<br>
This makes me uncomfortable (which I gather is what you're going for) in that<br>
not saying so, and maintaining compatibility to build with libgcc as the rtlib<br>
keeps us honest.<br>
<br>
<br>
Cheers,<br>
<br>
Jon<br>
><br>
> Ideas?<br>
><br>
> cheers,<br>
> --renato<br>
><br>
<span><font color="#888888"><br>
--<br>
Jon Roelofs<br>
<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a><br>
CodeSourcery / Mentor Embedded<br>
</font></span></blockquote></div><br></div></div>