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

[Benjamin Kramer]

On 01.06.2012, at 11:21, Alexey Samsonov wrote:

> 
> 
> On Fri, Jun 1, 2012 at 12:56 PM, Kostya Serebryany <kcc at google.com> wrote:
> 
> 
> On Fri, Jun 1, 2012 at 12:49 PM, Benjamin Kramer <benny.kra at googlemail.com> wrote:
> 
> On 01.06.2012, at 08:14, Kostya Serebryany wrote:
> 
> >
> >
> > 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.
> 
> It depends where you need to use LLVM libraries. Going back to the initial post of this thread, LLVM libraries will be used by asan/tsan to symbolicate stack traces. If that's the only use of LLVM in asan it would make a lot of sense to split that part into a DSO and link it on demand.
> 
> That'll work too and is indeed simpler. 
> 
> Yes. Is there an easy way to build that part of LLVM (Support and DebugInfo) as .so files as well as .a?


You want to create a new .so which links the .a files from LLVM and doesn't export LLVM's symbols. This is another advantage of using .so over .a, think of what will happen when you want to link LLVM trunk with asan which is using a different version of LLVM. LLVM's symbols are not versioned. With a DSO you can just hide all symbols except a couple of entry points for your purposes and none of the symbols will collide.

- Ben

> 
> --kcc 
>  
> That way we don't have to link all the (large) debug info code into every binary built with asan and have a nice workaround for the licensing issue.
> 
> I'm mildly opposed to relicensing parts of LLVM. While it makes sense to have lib/Support as liberally licensed as possible I'm afraid that it will creep into other parts too. Asking all developers to agree to a license change and reimplementing stuff written by people who won't answer is feasible but it will be painful and, in my opinion, a waste of development resources that are better spent improving LLVM.
> 
> - Ben
> 
> >
> > --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
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> 
> 
> 
> -- 
> Alexey Samsonov, MSK
>