llvm dev - Aug 2016 - [XRay][RFC] Tooling for XRay Trace Analysis

> On 26 Aug 2016, at 03:26, Chris Bieneman <cbieneman at apple.com>
wrote:
> 
> I totally did not mean to make the response off list.
> 
Thanks Chris, I'm adding the list to this response. Those interested should
see the short discussion quoted below.

Adding Chandler explicitly for points raised by Chris below. Thoughts?

Cheers

-- Dean
> 
>> On Aug 24, 2016, at 5:58 PM, Dean Michael Berris <dean.berris at
gmail.com> wrote:
>> 
>> 
>>> On 25 Aug 2016, at 04:27, Chris Bieneman <cbieneman at
apple.com> wrote:
>>> 
>>> 
>>> 
>>> On Aug 23, 2016, at 1:05 AM, Dean Michael Berris via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>> 
>>>> 
>>>> # Open Questions
>>>> 
>>>> - Is it possible to define the writer code in LLVM and have the
compiler-rt implementation depend on it? I hear that this is going to be useful
for something like the profiling library in compiler-rt too, so that the readers
and writer implementations are both in LLVM. What are the technical roadblocks
there, and in your opinion is this something worth fixing/enabling?
>>> 
>>> There are two problems with this.
>>> 
>>> (1) Compiler-RT is under a slightly different license from LLVM.
This complicates sharing code, or even moving code between the two projects.
Specifically, Compiler-RT's license does not require attribution for code
embedded in binaries, LLVM's does.
>>> 
>>> (2) Compiler-RT is commonly used without LLVM, and vice-versa.
Adding a dependency from Compiler-RT to LLVM breaks this, and fundamentally
alters the ways in which Compiler-RT can be used. While it would be possible to
say Xray requires LLVM, while the rest of Compiler-RT doesn't, I think this
would make a better argument for breaking Xray out of Compiler-RT rather than
changing Compiler-RT's dependency promise.
>>> 
>> 
>> Thanks Chris! I wasn't aware of the licensing difference. That does
complicate it a bit.
>> 
>> We've thought about breaking XRay out into a separate project, but
haven't gotten there yet because it's just much more convenient to host
it in already existing projects. Maybe it's time to think about this a bit
more seriously then.
>> 
>> Cheers
>> 
>> PS. I kept the reply just to you, not sure if you intended to reply
just to me or including the list.
>> 
>> -- Dean
>> 
>

The lack of possibility of code sharing makes me sad :(

CC: Rafael who has an outstanding patch to share code between LLVM and
compiler-rt (demangler), which can be a future concern with the licensing
difference Chris mentioned.

— 
Mehdi
> On Aug 25, 2016, at 11:58 PM, Dean Michael Berris via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> 
> 
>> On 26 Aug 2016, at 03:26, Chris Bieneman <cbieneman at apple.com>
wrote:
>> 
>> I totally did not mean to make the response off list.
>> 
> 
> Thanks Chris, I'm adding the list to this response. Those interested
should see the short discussion quoted below.
> 
> Adding Chandler explicitly for points raised by Chris below. Thoughts?
> 
> Cheers
> 
> -- Dean
> 
>> 
>>> On Aug 24, 2016, at 5:58 PM, Dean Michael Berris <dean.berris at
gmail.com> wrote:
>>> 
>>> 
>>>> On 25 Aug 2016, at 04:27, Chris Bieneman <cbieneman at
apple.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Aug 23, 2016, at 1:05 AM, Dean Michael Berris via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>>> 
>>>>> 
>>>>> # Open Questions
>>>>> 
>>>>> - Is it possible to define the writer code in LLVM and have
the compiler-rt implementation depend on it? I hear that this is going to be
useful for something like the profiling library in compiler-rt too, so that the
readers and writer implementations are both in LLVM. What are the technical
roadblocks there, and in your opinion is this something worth fixing/enabling?
>>>> 
>>>> There are two problems with this.
>>>> 
>>>> (1) Compiler-RT is under a slightly different license from
LLVM. This complicates sharing code, or even moving code between the two
projects. Specifically, Compiler-RT's license does not require attribution
for code embedded in binaries, LLVM's does.
>>>> 
>>>> (2) Compiler-RT is commonly used without LLVM, and vice-versa.
Adding a dependency from Compiler-RT to LLVM breaks this, and fundamentally
alters the ways in which Compiler-RT can be used. While it would be possible to
say Xray requires LLVM, while the rest of Compiler-RT doesn't, I think this
would make a better argument for breaking Xray out of Compiler-RT rather than
changing Compiler-RT's dependency promise.
>>>> 
>>> 
>>> Thanks Chris! I wasn't aware of the licensing difference. That
does complicate it a bit.
>>> 
>>> We've thought about breaking XRay out into a separate project,
but haven't gotten there yet because it's just much more convenient to
host it in already existing projects. Maybe it's time to think about this a
bit more seriously then.
>>> 
>>> Cheers
>>> 
>>> PS. I kept the reply just to you, not sure if you intended to reply
just to me or including the list.
>>> 
>>> -- Dean
>>> 
>> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On 26 August 2016 at 11:40, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> The lack of possibility of code sharing makes me sad :(
>
> CC: Rafael who has an outstanding patch to share code between LLVM and
compiler-rt (demangler), which can be a future concern with the licensing
difference Chris mentioned.

I think the demangler patch is fine since it is copying code from
libcxx-abi to llvm, so all code in there was OKed to be dual licensed.

Cheers,
Rafael