llvm dev - Feb 2014 - [LLVMdev] Sanitizers libs in Compiler-RT

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

On Sat, Feb 1, 2014 at 8:41 AM, Alex Rosenberg <alexr at ohmantics.com>
wrote:
> 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.
>
I think many, many folks need the sanitizers to be segregated into their
own runtime libraries.

In fact, from a functional perspective, many of the sanitizers' runtimes
are really mutually exclusive and should never even be in the same runtime
library.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140201/d9824e02/attachment.html>

Hi,
> 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.
Could you elaborate on this? I can't imagine how making sanitizer
runtime a shared library would help with the versioning problems,
other than create them. As a static library it is always in sync with
the compiler (unless someone wants to distribute them with an OS, of
course).

On 3 Feb 2014, at 08:32, Evgeniy Stepanov <eugenis at google.com> wrote:
>> 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.
> 
> Could you elaborate on this? I can't imagine how making sanitizer
> runtime a shared library would help with the versioning problems,
> other than create them. As a static library it is always in sync with
> the compiler (unless someone wants to distribute them with an OS, of
> course).
There are two issues with compatibility in the sanitiser libraries:

- Compiler-Runtime interfaces
- Runtime-OS interfaces

The first is made easier with a static library, the latter is made much harder
because modifying the OS (including libc and system calls) can break the static
library.

Both are made easy with a shared library.  The first can be addressed using
symbol versioning, the second by updating the shared library whenever the
underlying interfaces change.

David