[LLVMdev] Sanitizers libs in Compiler-RT

[Nick Kledzik]

On Jan 31, 2014, at 12:29 AM, Chandler Carruth <chandlerc at google.com> wrote:
> I thought some of it still need libunwind (whichever of the various versions you like)? It would be good to get a nice, clean implementation of that functionality (whether based on one with an MIT license if there is such or not) if we don't already have it.
The unwinder in libcxxabi implements both the _Unwind_* functions needed by libcxxabi and the unw_* functions that are the “libunwind” API.  There is nothing more needed.


On Jan 31, 2014, at 12:23 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote
> On 31 Jan 2014, at 08:12, Chandler Carruth <chandlerc at google.com> wrote:
> 
>> - There is the core runtime library. Historically this was called 'compiler-rt' informally, but perhaps better called 'libclang_rt', which provides the core necessary runtime library facilities to compile C or C++ applications. It's analogous to libgcc but without some of the unwinding code (as I understand it, there may be details I'm wrong about here or glossing over, but it's not relevant to the organization of things).
> 
> For some reason, the (generic, language-agnostic) unwind code is in libcxxabi.  There was some discussion about moving it into the compiler-rt repository, where it would make sense.  No one objected, but I'd rather not move it without a 'yes' from someone who is actually working on the code currently (I'd like to start factoring out the #ifdefs into a cleaner platform / architecture layer).

The logic was that libcxxabi is the biggest client of the unwinder, and well, compiler-rt was already complicated enough ;-)  That said, if we had a nice clean, scalable model for organizing all the runtime support libraries, I’d be happy to migrate the unwinder there.

Also, to help explain my bias, at Apple, the unwinder (and libc++abi) are dylibs that ship as part of the OS.  They have nothing to do with the compiler. 


A couple of other random thoughts about compiler-rt:

* One of the makefile dimensions of complexity is the ability to build optimized, profile, and debug copies of everything.  This was once needed at Apple, but no longer is necessary.

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

-Nick