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

Fri Jun 1 02:21:19 PDT 2012

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?

>
> --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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120601/a8668910/attachment.html>