[LLVMdev] Sanitizers libs in Compiler-RT

[David Chisnall]

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

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

On FreeBSD, the main consumers of the unwind library are:

- libgcc_s / compiler-rt (our libgcc_s.so actually uses compiler-rt code here) for the C personality function.
- libcxxrt for the C++ personality function
- libobjc for the Objective-C and Objective-C++ personality functions (libobjcxx on older versions where the C++ ABI library is not dynamically linked).

Thus we'd like to import and contribute to a cleaner unwind library, but for us the code will end up in a libgcc_s replacement, and so having it in the same place as the rest of the libgcc_s replacement code (compiler-rt) seems more obvious.

Having a library as a child of one of its consumers is a bit odd.

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

We also ship compiler-rt as part of the OS, not specifically as part of the compiler (the same is true of libgcc* and crt*), so I don't understand this argument.

David