[LLVMdev] LibUnwind into Compiler-RT?

[Nick Kledzik]

On Oct 22, 2014, at 12:03 PM, Renato Golin <renato.golin at linaro.org> wrote:

> On 22 October 2014 19:24, Jonathan Roelofs <jonathan at codesourcery.com> wrote:
>> 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?
> 
> Yeah, it's hard and clumsy, not impossible.
> 
> Basically, I want to avoid requiring people to link against
> libunwind+rt+libcxxabi if all they need is libcxx or rt.
> 
> 
>>> 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... ;)
> 
> I know, I put it there. :)
> 
> I did it because that was what libgcc required, and I didn't want to
> make compiler-RT depend on libc++, at least not at a Clang level.
> Since gcc_s and gcc_eh are both provided by libgcc, it makes sense in
> the GNU case. Maybe, a better approach would be to warn users if they
> choose compiler-rt (via --rtlib=compiler-rt) and not libunwind or
> libgcc_s variants.
> 
> The other problem is symbol clashing. If we start including multiple
> libraries that implement and export the same symbols, we'll be in
> trouble soon enough. This already happens with --rtlib=compiler-rt and
> will happen if I include -lgcc_s on libc++abi tests on ARM (for the
> RTABI part). Having libunwind on its own repository is also not a
> horrible idea, but I don't know the logistics of that.
> 
> 
>>> 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.
> 
> Me too, but I have to say it's by far the easiest option.
> 
> We only have that kind of problem because we split the symbols in a
> way that is different than GNU tools, so that we'll always have
> clashes when we try to interoperate. The other easy option is to split
> in the *exact* same way as libgcc, so that we can mix and match, but
> that's not free of problems, either.

The only idea I heard back when this was previously discussed would be
to put all of compiler-rt, libunwind, and libc++abi into one project with
platform specific build rules to pull the right mix of code into the right
libraries for each platform.
But at the time compiler-rt had a “very unique” build system, making it
hard to merge with other more conventional CMake based systems.

> Someone with more knowledge in linkers can chime in on how the symbols
> are dropped, so that at least we can be sure of which library
> overrides which.
I do know that libunwind is API compatible with libgcc_s but uses different 
data structure layouts, so the two are not ABI compatible.  That means
in any process all the unwinding APIs have to come one or the other - no mixing.

-Nick