[LLVMdev] LibUnwind into Compiler-RT?

[Renato Golin]

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.

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.

cheers,
--renato