[LLVMdev] Using LLVM code in projects/compiler-rt

[Kostya Serebryany]

On Fri, Jun 1, 2012 at 7:13 AM, Chris Lattner <clattner at apple.com> wrote:

> On May 31, 2012, at 6:48 PM, Chandler Carruth wrote:
>
> I'm not sure that this solves the problem.  The reason we have dual
>> licenses for the runtime stuff is that we don't want the UIUC license
>> (which has a binary attribution clause) to affect stuff built with the
>> compiler.  Saying that "clang -fasan produces code that has to binary
>> attribute the LLVM license" is pretty lame.
>>
>
> I think that what is *traditionally* thought of as compiler-rt has
> different needs from ASan/TSan/etc. The latter runtimes are really intended
> to be separate units from the binary; for example none of their code would
> ever be directly emitted into a function, etc. Certainly the scope and
> complexity of them are very different, and so it might still make sense to
> split these into two groups of runtime libraries.
>
>
> To be clear, compiler-rt isn't injected into functions.  Maybe a better
> definition is that compiler-rt is statically linked in, vs the more
> advanced runtimes that are dynamically linked in.
>
> Forming the division like this might make it easier to handle the
> attribution issues too enough trickery.
>
> Were I drawing an arbitrary line, I would draw it around the runtime
> libraries which are stand-alone and implement an available spec for which
> other implementations can and do exist. (libgcc, libstdc++, etc etc.)
> Regardless of licensing issues, I suspect making this bucketing more clear
> would simplify some of these projects....
>
>
> Yeah, I completely agree with your goals.  This is one of the big concerns
> I had back when the dual licensing happened in the first place.
>
>
> Anyways, there seem to be a few, all somewhat bad options left to us with
> ASan/TSan and similar more "advanced" runtimes:
>
> 1) Swallow the lame binary attribution clause requirement. Document this
> noisily.
> 2) Require they are build as DSOs, and thus the attribution restricted to
> that runtime library entity.
>
>
> Maybe 2a: engineer asan so that it *optionally* links to the DSO.  If the
> DSO is present, functionality is enabled, if not, it is silently disabled
> and the app still works (at some performance cost).   Could this work?
>

DSO? You mean to make asan.so instead of asan.a?
This will work, but may cause confusion. If asan.so is not present, the
asan-ified binary will crash instantly.

For tsan, making it tsan.so instead of tsan.a will cause a huge performance
penalty because tsan reads TLS on every memory access.

--kcc



>
> 3) Build the functionality needed by ASan/TSan/etc independently of LLVM's
> core libraries. Code duplication here, and only a dim hope that we could
> package in a way that lldb or others might be able to shift to depend upon
> the dual-licensed functionality rather than the core LLVM functionality.
> 4) Start moving core LLVM libraries into a separate 'core library' or
> 'common library' project which has the dual-license requirement, but is a
> "lower-level" component than LLVM itself.
>
>
> #4 is somewhat independently useful anyway.  The support and system
> libraries are the lowest level (from a layering perspective) and most
> reusable across sub-projects.  Actually relicensing them would be a major
> effort though.
>
> #3 seems like painting ourselves into a corner, and borrowing a lot of
> technical debt in the future. I suspect we'll keep having to replicate
> functionality here.
>
>
> Yeah.
>
> #4 is interesting, but a *ton* of work. The Object library, most of
> Support and System, all would have to sink into this core module, all would
> have to get dual-licensed (ow!!! how? some of the contributors are around
> to agree to new license, but not all... likely a fair amount of rewrite
> required to produce new versions of libraries under the correct license).
>
>
> I think that #4 is the best long term answer, but yeah... oww.  If you're
> interested in stack traces in particular, making pieces "optionally
> enabled" seems really attractive.
>
> -Chris
>
> _______________________________________________
> 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/llvm-dev/attachments/20120601/14c1c7e2/attachment.html>