[LLVMdev] LibUnwind into Compiler-RT?

[Dan Albert]

>
> 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 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
>
>
>
>
>
> _______________________________________________
> 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>