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

[Chandler Carruth]

On Thu, May 31, 2012 at 5:39 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On May 31, 2012, at 1:20 PM, Chandler Carruth wrote:
>
> On Thu, May 31, 2012 at 1:13 PM, Rafael Espíndola <
> rafael.espindola at gmail.com> wrote:
>
>> On 31 May 2012 05:02, Alexey Samsonov <samsonov at google.com> wrote:
>> > Hi,
>> >
>> > tl;dr How can I include LLVM headers and use code from libLLVM*.a files
>> when
>> > building compiler-rt libraries?
>>
>> LLVM and compiler-rt  have different licenses (compiler-rt is dual
>> licensed with the MIT license). Would that be a problem?
>>
>
> This is a good point…
>
>
> Yes it is, it would be a problem :-(
>
> Chris, I'm wondering whether putting all of the runtimes into
> 'compiler-rt' is really the best structure at this point... What would seem
> a somewhat less awkward fit to me these days:
>
> - a runtimes project which contains various runtime libraries, under the
> usual LLVM license
> - the original 'compiler-rt' bits either as a sub-library of this which
> happens to be buildable stand-alone and dual-licensed, or as its own
> entirely separate project
> - coverage profile runtime, asan, tsan, and common runtime libraries
> separated out from compiler-rt
>
>
> We can achieve the same technical result with the current structure, but
> its inverted and awkward: the restrictive rules (dual license / stand-alone
> build) are enforced in an outer layer, with the permissive rules returning
> in an inner layer (the asan or tsan runtimes themselves).
>
> Thoughts?
>
> If this is the direction to go, I'm happy to do the lion share of leg work
> to re-organize (with the help of ASan folks)... I think my personal
> preference would be for compiler-rt to be a separate top-level project from
> a generic 'runtimes' project.
>
>
> 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.

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


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

#1 and #2 are at least clear in how they would work. They have downsides,
but not in terms of implementation.

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

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