<div dir="ltr"><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"><span style="font-family:arial,sans-serif;font-size:13px">The question is whether or not you want to support non-clang compiled code with libunwind</span></blockquote><div><br></div><div>This is required for Android for the time being.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 22, 2014 at 7:11 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Oct 22, 2014, at 12:03 PM, Renato Golin <<a href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>> wrote:<br>
<br>
> On 22 October 2014 19:24, Jonathan Roelofs <<a href="mailto:jonathan@codesourcery.com">jonathan@codesourcery.com</a>> wrote:<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>
> Yeah, it's hard and clumsy, not impossible.<br>
><br>
> Basically, I want to avoid requiring people to link against<br>
> libunwind+rt+libcxxabi if all they need is libcxx or rt.<br>
><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>
> I know, I put it there. :)<br>
><br>
> I did it because that was what libgcc required, and I didn't want to<br>
> make compiler-RT depend on libc++, at least not at a Clang level.<br>
> Since gcc_s and gcc_eh are both provided by libgcc, it makes sense in<br>
> the GNU case. Maybe, a better approach would be to warn users if they<br>
> choose compiler-rt (via --rtlib=compiler-rt) and not libunwind or<br>
> libgcc_s variants.<br>
><br>
> The other problem is symbol clashing. If we start including multiple<br>
> libraries that implement and export the same symbols, we'll be in<br>
> trouble soon enough. This already happens with --rtlib=compiler-rt and<br>
> will happen if I include -lgcc_s on libc++abi tests on ARM (for the<br>
> RTABI part). Having libunwind on its own repository is also not a<br>
> horrible idea, but I don't know the logistics of that.<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>
> Me too, but I have to say it's by far the easiest option.<br>
><br>
> We only have that kind of problem because we split the symbols in a<br>
> way that is different than GNU tools, so that we'll always have<br>
> clashes when we try to interoperate. The other easy option is to split<br>
> in the *exact* same way as libgcc, so that we can mix and match, but<br>
> that's not free of problems, either.<br>
<br>
</div></div>The only idea I heard back when this was previously discussed would be<br>
to put all of compiler-rt, libunwind, and libc++abi into one project with<br>
platform specific build rules to pull the right mix of code into the right<br>
libraries for each platform.<br>
But at the time compiler-rt had a “very unique” build system, making it<br>
hard to merge with other more conventional CMake based systems.<br>
<span class=""><br>
> Someone with more knowledge in linkers can chime in on how the symbols<br>
> are dropped, so that at least we can be sure of which library<br>
> overrides which.<br>
</span>I do know that libunwind is API compatible with libgcc_s but uses different<br>
data structure layouts, so the two are not ABI compatible.  That means<br>
in any process all the unwinding APIs have to come one or the other - no mixing.<br>
<br>
-Nick<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div>