On 30 January 2014 20:33, Reid Kleckner <rnk at google.com> wrote:> Basically, compiler-rt contains the only runtime libraries we ship with > Clang. The sanitizers are runtime libraries shipped with clang (they have > some version dependence), so they went in compiler-rt. Now they are > starting to feel much larger than compiler-rt, so perhaps they should be > split out. > > Or we can leave them there and solve your ARM build problems a different > way. >Right, I apologise for my lack of specificity... I do remember that thread, what I was referring to was exactly what you said. My premise: 1. I want to make Compiler-RT work on ARM and be a drop-in replacement for libgcc, to the point where it'll become the standard compiler library for LLVM in the near future. My bold plans are to have that in 3.5, but I won't be unhappy if we at least get it working until then. 2. I don't want to have the huge effort right now, to port a library that was mainly developed by and on x86_64 *just because* I want compiler-rt to work on ARM. This can work in several ways: A. I compile the whole lot, but only grab the compiler-rt library when packaging. B. I change the CMalke files to only compiler RT on ARM, or any other architecture that wants only RT C. We split the libraries If the consensus is that the sanitizers are a lot bigger than RT and should split for that reason, I'm fine with it. If not, I'm also fine with having a CMake configuration to only build what's needed. I'd be less fine with compiling everything, testing (or ignoring) everything, because that'll strain our native bots (that are still dead slow) and will also increase the signal-to-noise ration on bugs and crashes, but ultimately, I would be ok with it, as a first approach. Makes sense? cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140130/a4275e5d/attachment.html>
On Thu, Jan 30, 2014 at 1:19 PM, Renato Golin <renato.golin at linaro.org>wrote:> On 30 January 2014 20:33, Reid Kleckner <rnk at google.com> wrote: > >> Basically, compiler-rt contains the only runtime libraries we ship with >> Clang. The sanitizers are runtime libraries shipped with clang (they have >> some version dependence), so they went in compiler-rt. Now they are >> starting to feel much larger than compiler-rt, so perhaps they should be >> split out. >> >> Or we can leave them there and solve your ARM build problems a different >> way. >> > > Right, I apologise for my lack of specificity... I do remember that > thread, what I was referring to was exactly what you said. > > My premise: > > 1. I want to make Compiler-RT work on ARM and be a drop-in replacement for > libgcc, to the point where it'll become the standard compiler library for > LLVM in the near future. My bold plans are to have that in 3.5, but I won't > be unhappy if we at least get it working until then. > > 2. I don't want to have the huge effort right now, to port a library that > was mainly developed by and on x86_64 *just because* I want compiler-rt to > work on ARM. > > This can work in several ways: > > A. I compile the whole lot, but only grab the compiler-rt library when > packaging. > B. I change the CMalke files to only compiler RT on ARM, or any other > architecture that wants only RT > C. We split the libraries > > If the consensus is that the sanitizers are a lot bigger than RT and > should split for that reason, I'm fine with it. If not, I'm also fine with > having a CMake configuration to only build what's needed. I'd be less fine > with compiling everything, testing (or ignoring) everything, because > that'll strain our native bots (that are still dead slow) and will also > increase the signal-to-noise ration on bugs and crashes, but ultimately, I > would be ok with it, as a first approach. >I don't see any compelling reason to split the sanitizers out today. I think the sanitizer guys would probably take a patch to CMakeLists.txt to disable the sanitizer RTLs. I'm told that ASan supports ARM, but it's maybe not production quality, so I don't think disabling all sanitizers on non-x86 architectures will work. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140130/b7f595eb/attachment.html>
On 30 January 2014 21:50, Reid Kleckner <rnk at google.com> wrote:> > I don't see any compelling reason to split the sanitizers out today. >Clear, next. I think the sanitizer guys would probably take a patch to CMakeLists.txt to> disable the sanitizer RTLs. >Right. I'll first make it build and test, than I'll disable via a flag, since other people can work in parallel to make it work on ARM. I'm told that ASan supports ARM, but it's maybe not production quality, so> I don't think disabling all sanitizers on non-x86 architectures will work. >I hear Android folks use it, this is why I want to enable them by default. Even if the tests don't mean much, at least there's a seed from where they can pick that up and complete the port. I'm fine on building them on my own, but buildbots and release builds should not need to, if it's not suitable. Thanks, that answers all my questions. I'll proceed with my changes. --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140130/eb901121/attachment.html>
> On Jan 30, 2014, at 1:50 PM, Reid Kleckner <rnk at google.com> wrote:> >> On Thu, Jan 30, 2014 at 1:19 PM, Renato Golin <renato.golin at linaro.org> wrote: >>> On 30 January 2014 20:33, Reid Kleckner <rnk at google.com> wrote: >>> Basically, compiler-rt contains the only runtime libraries we ship with Clang. The sanitizers are runtime libraries shipped with clang (they have some version dependence), so they went in compiler-rt. Now they are starting to feel much larger than compiler-rt, so perhaps they should be split out. >>> >>> Or we can leave them there and solve your ARM build problems a different way. >> >> Right, I apologise for my lack of specificity... I do remember that thread, what I was referring to was exactly what you said. >> >> My premise: >> >> 1. I want to make Compiler-RT work on ARM and be a drop-in replacement for libgcc, to the point where it'll become the standard compiler library for LLVM in the near future. My bold plans are to have that in 3.5, but I won't be unhappy if we at least get it working until then. >> >> 2. I don't want to have the huge effort right now, to port a library that was mainly developed by and on x86_64 *just because* I want compiler-rt to work on ARM. >> >> This can work in several ways: >> >> A. I compile the whole lot, but only grab the compiler-rt library when packaging. >> B. I change the CMalke files to only compiler RT on ARM, or any other architecture that wants only RT >> C. We split the libraries >> >> If the consensus is that the sanitizers are a lot bigger than RT and should split for that reason, I'm fine with it. If not, I'm also fine with having a CMake configuration to only build what's needed. I'd be less fine with compiling everything, testing (or ignoring) everything, because that'll strain our native bots (that are still dead slow) and will also increase the signal-to-noise ration on bugs and crashes, but ultimately, I would be ok with it, as a first approach. > > I don't see any compelling reason to split the sanitizers out today. I think the sanitizer guys would probably take a patch to CMakeLists.txt to disable the sanitizer RTLs.One organizational thought to add: For us, the sanitizers contain behaviors/syscalls that are not valid on consumer hardware. They perform "debug" functionality and thus can only operate on special developer kits. Additionally, we need to put this type of code into a dynamic library instead of a static library to avoid versioning problems. I agree that this is all part of compiler_rt as a project/repo, but the sanitizers should remain segregated into their own runtime library. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140201/5bb3b0f4/attachment.html>