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

[Sean Silva]

On Sat, Feb 1, 2014 at 6:10 AM, Renato Golin <renato.golin at linaro.org>wrote:

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

FYI the name "libclang" is already in use <
http://clang.llvm.org/docs/Tooling.html#libclang>, so a different name
would need to be chosen.

-- Sean Silva


>
> 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
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140202/2c103c84/attachment.html>