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

[Renato Golin]

On 1 February 2014 00:44, Nick Kledzik <kledzik at apple.com> wrote:

> * One of the interesting things about compiler-rt is the static library to
> dynamic library migration (e.g. libgcc.a vs libgcc_s.so, or on Darwin
> libclang_*.a vs libSystem.dylib).  If the shared library ships
> independently from the compiler, then the compiler may need a .a file that
> can ship with it that contains any support functions not available in a
> shared library on the target.  Currently, it is a very manual process to
> figure out which functions are needed where.
>
> * It would be nice if the clang build system could output a list of all
> possible support functions it might need for compiler being built.  That
> list could drive what parts of compiler-rt need to be built.
>
> So, to me an ideal build system for compiler-rt would not just compile the
> snippets of code, it would figure out which snippets to build based on what
> the compiler needs and what the OS needs/provides.
>

Hi Nick,

These features would be great, but I think it's too complex to migrate from
what we have today to that scenario and people won't buy-in that easily.

I think the fact that all sanitizers, profilers and possibly unwinders have
their libraries in there is a good reason for us to have separate builds of
each library and treat "Compiler-RT" as a repository for run-time
libraries, rather than a library in itself.

I'm in favour of naming what we call today "compiler-rt" to "libclang" and
moving libcxxabi into it as "libunwind" or anything relevant, but to softly
migrate the interactions between RT and Clang over time.

A few steps like:

1. Move libraries in, rename, compile everything everytime
2. Separate libraries' build systems, disable via flags / arch support (on
both clang and rt)
3. Get Clang to list *libraries* needed, and make RT's make system to only
build those
4. Get Clang to list *functions* needed, and update RT's make system
accordingly

I think having step 3 would be amazing, but 2 is already good for all
practical purposes. Step 4 is way past *my* needs, but I don't think it's a
bad thing to have.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140201/c6f03b44/attachment.html>