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

Renato Golin renato.golin at linaro.org
Wed Oct 22 12:03:42 PDT 2014

On 22 October 2014 19:24, Jonathan Roelofs <jonathan at codesourcery.com> wrote:

I do compilerrt + 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 compilerrt?

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 gcceh and gccs 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

More information about the llvm-dev mailing list