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

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Fri Sep 9 09:05:47 PDT 2016


On Thu, Sep 8, 2016 at 11:34 PM Dean Michael Berris <dean.berris at gmail.com>
wrote:

>
> > On 9 Sep 2016, at 12:35, Dean Michael Berris <dean.berris at gmail.com>
> wrote:
> >
> >
> >
> >> On 7 Sep 2016, at 01:21, David Blaikie <dblaikie at gmail.com> wrote:
> >>
> >> But I take it you mean (as detailed later) to have a separate format
> (could be a portable binary format, but currently discussing it as
> JSON/YAML/etc) that things are converted from that makes them portable?
> >>
>
> One thing worth mentioning on this regard is maybe we can use Flatbuffers (
> https://google.github.io/flatbuffers/) for the XRay log.
>

For the secondary form (instead of YAML/JSON) or the primary form (the
thing compiler-rt writes out)? Or as a form that would cover both use cases
without the need to convert from one format to another?


>
> Flatbuffers is Apache 2 licensed though, and if we're going to use it in
> compiler-rt, whether that raises issues if embedded in other people's
> applications.
>
> This might potentially get us around the non-sharing of code if we're able
> to keep the flatbuffer definitions in sync at least across compiler-rt and
> LLVM. Also, it might be useful to use flatbuffers for other things in LLVM
> as well so that might be something worth exploring (the bit code comes to
> mind, somehow being discussed on IRC recently).
>
> I am not a lawyer nor do I play one on the Internet, so I'll let Danny
> Berlin chime in on this one on whether/how we can use Flatbuffers for XRay.
>
> -- Dean
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160909/ba892013/attachment.html>


More information about the llvm-dev mailing list