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>
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?> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120531/70fe1fe4/attachment.html>
> > #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).You actually don't have that many contributors. I've seen this done for projects with 200+ contributors. Even better, most LLVM contributors are still around. If you have to rewrite a little code along the way to account for folks you can't find, this is probably worth the expense anyway (and i'm pretty sure we'd be happy to fund it :P). The more interesting question is whether you want to dual license, add a general exception to the LLVM license, or switch wholesale to MIT license.
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>
On Fri, Jun 1, 2012 at 10:10 AM, Daniel Berlin <dberlin at dberlin.org> wrote:> > > > #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). > > You actually don't have that many contributors. I've seen this done > for projects with 200+ contributors. > Even better, most LLVM contributors are still around. > If you have to rewrite a little code along the way to account for > folks you can't find, this is probably worth the expense anyway (and > i'm pretty sure we'd be happy to fund it :P). > > The more interesting question is whether you want to dual license, add > a general exception to the LLVM license, or switch wholesale to MIT > license. >All of asan and tsan code is authored by us (except maybe a couple of one-line hot fixes when we broke the build and someone else fixed it). As far as I am concerned, either license is fine. --kcc> _______________________________________________ > 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/d7f629bf/attachment.html>
On Thu, May 31, 2012 at 11:10 PM, Daniel Berlin <dberlin at dberlin.org> wrote:> > > > #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). > > You actually don't have that many contributors. I've seen this done > for projects with 200+ contributors. > Even better, most LLVM contributors are still around. > If you have to rewrite a little code along the way to account for > folks you can't find, this is probably worth the expense anyway (and > i'm pretty sure we'd be happy to fund it :P). >After talking with DannyB, I now am strongly in the camp that we should do #4 whole-sale, and make everything hold a license that works for runtimes. We can potentially move completely away from dual-licensing. We can definitely drive this effort if the community is supportive, including re-writing parts of the codebase from authors we can't contact.> The more interesting question is whether you want to dual license, add > a general exception to the LLVM license, or switch wholesale to MIT > license. >This is indeed the question: what should the end state be. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120531/e3332d60/attachment.html>