Hi all, Can anyone explain me what was the rationale behind putting the sanitizer libraries in compiler-rt? The sanitizers only work properly in x86_64 and I don't see anyone even testing to any other platform, while compiler-rt should be a substitute for libgcc on all platforms, at least that's the goal, and linking the success of the RT library to the success of the sanitizers is a bit of an oversight, IMHO. I'm spending 99% of the time to make compiler-rt compiler on ARM using CMake by fiddling the sanitizers' tests, lit config files and CMake scripts, which is a bit annoying... Long term, would it be possible / desirable to split them into compiler-rt and sanitizer-rt? cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140130/dccd28f0/attachment.html>
On 30/01/2014 19:07, Renato Golin wrote:> Hi all, > > Can anyone explain me what was the rationale behind putting the > sanitizer libraries in compiler-rt? > > The sanitizers only work properly in x86_64 and I don't see anyone > even testing to any other platform, while compiler-rt should be a > substitute for libgcc on all platforms, at least that's the goal, and > linking the success of the RT library to the success of the sanitizers > is a bit of an oversight, IMHO. > > I'm spending 99% of the time to make compiler-rt compiler on ARM using > CMake by fiddling the sanitizers' tests, lit config files and CMake > scripts, which is a bit annoying... > > Long term, would it be possible / desirable to split them into > compiler-rt and sanitizer-rt?I don't know about the specific problems you've faced on ARM, but I'd like to add that these problems also exist on x86, where the sanitizers aren't fully supported on OS X, Windows or even various Linux distributions outside the configuration the authors have. Moreover the project seems to have a different development and review policy to the rest of LLVM and it's been difficult at times to align that with general interests on the clang side. That said, let's engage the developers before jumping to conclusions. The sanitizer work happens off in a corner and we tend to only notice it when it gets in our way. If the sanitizers are spun off, it should be done to make those developers work easier, not just ours. Alp. -- http://www.nuanti.com the browser experts
Hi Renato, On Thu, Jan 30, 2014 at 11:07 PM, Renato Golin <renato.golin at linaro.org>wrote:> Hi all, > > Can anyone explain me what was the rationale behind putting the sanitizer > libraries in compiler-rt? > > The sanitizers only work properly in x86_64 and I don't see anyone even > testing to any other platform, while compiler-rt should be a substitute for > libgcc on all platforms, at least that's the goal, and linking the success > of the RT library to the success of the sanitizers is a bit of an > oversight, IMHO. > > I'm spending 99% of the time to make compiler-rt compiler on ARM using > CMake by fiddling the sanitizers' tests, lit config files and CMake > scripts, which is a bit annoying... >If you're only interested in building compiler-rt library for ARM, and not interested in supporting sanitizers on that platform, you can just avoid building them on ARM. You're right that it takes explicit effort to enable building sanitizers on ARM, but IMO that's not accidental or bad - we *don't* want to build them unless there is an interest in support.> > Long term, would it be possible / desirable to split them into compiler-rt > and sanitizer-rt? > > cheers, > --renato > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- Alexey Samsonov, MSK -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140130/b3e4cd43/attachment.html>
On Thu, Jan 30, 2014 at 11:07 AM, Renato Golin <renato.golin at linaro.org>wrote:> Hi all, > > Can anyone explain me what was the rationale behind putting the sanitizer > libraries in compiler-rt? >http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-November/045444.html 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140130/63482fe3/attachment.html>
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>