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

Dan Albert danalbert at google.com
Wed Oct 22 19:45:18 PDT 2014

The question is whether or not you want to support non-clang compiled code with libunwind

This is required for Android for the time being.

On Wed, Oct 22, 2014 at 7:11 PM, Nick Kledzik <kledzik at apple.com> wrote:

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

LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141022/cdf408c8/attachment.html>

More information about the llvm-dev mailing list