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
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
> > The question is whether or not you want to support non-clang compiled code > with libunwindThis 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>
On 23 October 2014 03:11, Nick Kledzik <kledzik at apple.com> wrote:> 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.This would be a build nightmare, but if people more familiar with CMake are comfortable, I'm ok with it.> 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.I didn't mean mixing unwind libraries themselves, but mixing libgcc + libunwind or compiler-rt + libgcc_s or compiler-rt + libunwind. The problem is that libgcc_s contains some, but not all, of the unwind routines, in addition to RT calls (such as hardware divide, etc). For that reason, libunwind cannot be linked with libgcc without libgcc_s on ARM. Also, libgcc_eh has the rest of the unwinding functions for C++, which is more in line with libc++, not libunwind or libc++abi. Is there any case where people use libc++ with libgcc? Or are all toolchains using compiler-rt? I can do that, at least on ARM, so that we avoid any code movement for the time being. I don't *need* to use libgcc at all, I'm just trying to figure out the best way to do things on ARM. cheers, --renato