[cfe-dev] [LLVMdev] Sanitizers libs in Compiler-RT

[Renato Golin]

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/cfe-dev/attachments/20140130/a4275e5d/attachment.html>