[PATCH] D21987: [XRay] Implement `llvm-xray extract`, start of the llvm-xray tool

[David Blaikie via llvm-commits]

On Tue, Sep 13, 2016 at 10:30 PM Dean Michael Berris <dberris at google.com>
wrote:

> On Tue, Sep 13, 2016 at 10:48 AM David Blaikie <dblaikie at gmail.com> wrote:
>
> On Mon, Sep 12, 2016 at 5:43 PM Dean Michael Berris <dberris at google.com>
> wrote:
>
> On Tue, Sep 13, 2016 at 2:43 AM David Blaikie <dblaikie at gmail.com> wrote:
>
>
> I think the concern of whether the writing tool can be run correctly
> across platform is something to resolve first. I expect test cases for the
> tool to involve checked in binaries and executed on all test configurations
> in LLVM. It's just a tool reading a file and producing another file or the
> stats, etc.
>
>
> With the changes lined up after this one, we don't need to check in
> binaries -- we can write the log files in YAML and have them converted to
> particular targets, when we support them.
>
>
> OK, but the functionality would still be missing - in the sense that one
> couldn't take a file from one machine to another, then run the tool on it.
> I think that's, imho (others may fairly disagree - happy to chat more with
> Eric & Chandler, for example), a blocker. The tool should be able to read
> the file no matter which host we're on.
>
>
> I think this is exactly what I meant -- that since this is a reciprocal
> feature (writing/reading) then it will imply that we can convert from
> whatever binary format from whatever platform to YAML and back. We just
> have to test those. :)
>

Sorry, I think I've lost the thread of this conversation, perhaps we're
talking past each other.

It sounded like when you said this:

"With the changes lined up after this one, we don't need to check in
binaries -- we can write the log files in YAML and have them converted to
particular targets, when we support them."

we would only test roundtripping on the same platform (YAML->host binary
format->YAML) which wouldn't demonstrate that we could read the binary
format of a different host, which is the functionality I'm suggesting is
probably important/necessary.


>
>
>
>
> Not only then can we read them in a platform-specific format we can write
> them in that format too. Might be a little more work, but the choice here
> is doing that versus using Flatbuffers (i.e. being more clever about it).
>
>
> Not entirely following - but you're suggesting that portable reading of
> these splatted files is not practical, or at least it would be enough work
> that we might as well just do Flatbuffers from the get-go?
>
>
>
> I'm suggesting that the amount of work will practically be the same in the
> case of 2 or 3 platforms -- any more and then Flatbuffers would be a better
> (albeit more expensive) approach. That we should do it when we have more
> platforms supported.
>
> Cheers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160915/c700ccfc/attachment.html>