similar to: RFC: XRay Profiling in LLVM

FYI: Patch is now available for review in https://reviews.llvm.org/D44620. On Thu, Feb 15, 2018 at 1:34 PM Dean Michael Berris <dean.berris at gmail.com> wrote: > # Objective > > Implement an XRay mode 'xray-profiling' that gathers stack trace > latencies/durations and builds histograms to provide basic statistics about > where time is going in an execution of the

Hi llvm-dev, Recently, we've committed the beginnings of the llvm-xray [0] tool which allows for conveniently working with both XRay-instrumented libraries as well as XRay trace/log files. In the course of the review for the conversion tool [1] which turns a binary/raw XRay log file into YAML for human consumption purposes, a question arose as to how we intend to allow users to develop tools

I'm still somewhat unclear about what you mean by "metadata record entry at the beginning of the block". I understand that I can make a MetadataRecord that contains the pid/tid since a metadata record contains 16 bytes. However, I don't understand what do you mean by the "beginning of the block". Do you mean right after the file header? My understanding is that at

On Sun, Mar 12, 2017, 4:10 PM Dean Michael Berris <dean.berris at gmail.com> wrote: > > > On 9 Mar 2017, at 09:32, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > I agree that we should clean up the standard library usage even just for > consistency. > > > > +1 -- now that I think about it, it should be fairly doable

On Wed, Mar 8, 2017 at 2:28 PM Tim Shen <timshen at google.com> wrote: > On Wed, Mar 8, 2017 at 1:49 PM David Blaikie <dblaikie at gmail.com> wrote: > > So I stumbled across an issue that I think is a bit fundamental: > > The xray runtime uses the C++ standard library. > > This seems like a problem because whatever C++ standard library is used to > compile the

Hello, I am initializing FDR mode and finalizing/flushing the buffers manually. XRay does not log calls from the main thread unless there is a function call after __xray_log_finalize(). This behavior is abnormal since one would expect the trace file to contain all function calls made up to the point when __xray_log_finalize() is called. To demonstrate this behavior, I have taken the test case

I would be happy to help. Could you send me the example patch? Where would I submit my patch to be reviewed? Thanks, Henry On Mon, Jun 11, 2018 at 8:31 PM, Dean Michael Berris <dean.berris at gmail.com> wrote: > > > > On 12 Jun 2018, at 07:49, Henry Zhu via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hello, > > > > > > I’ve

Hello, There seems to be a bug with the value of the thread ID (TID) that is generated by XRay when calling fork(). The value of the TID of the child has the same TID as its parent (this is seen in the “thread: “ field of the YAML output produced by the llvm-xray tool). This is a problem as the trace generated contains the same TID for the parent and children processes, making it difficult to

Hello, Also, I’ve noticed that FDR mode doesn’t flush to a log unless programmatically configured to do so unlike basic mode, which flushes by default. Would it be possible to add this feature as well? Thanks, Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180611/295c3dba/attachment.html>

Hi Dean, I haven't looked very closely at XRay so far, but I'm wondering if making CTF (common trace format, e.g. see http://diamon.org/ctf/) the default format for XRay traces would be useful? It seems it'd be nice to be able to reuse some of the tools that already exist for CTF, such as a graphical viewer (http://tracecompass.org/) or a converter library

Hello, I’ve noticed that XRay does not report the PID in the trace log. Could this be added for multi-process support? (Maybe as a command line argument). Thanks, Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180611/f800c333/attachment.html>

Hi cfe-dev@ and llvm-dev@, I've attached a Chrome trace-viewer readable trace of a clang built with XRay instrumentation (additional build/link flags="-fxray-instrument -fxray-instruction-threshold=75") with the latest "top-of-trunk" version of clang with the recent updates to the XRay runtime supporting record filtering. To load the attached file, go to

On Mon, Jan 7, 2019 at 3:21 PM Dean Michael Berris <dean.berris at gmail.com> wrote: > On Mon, Jan 7, 2019 at 8:43 PM Dangeti Tharun kumar > <cs15mtech11002 at iith.ac.in> wrote: > > > > Hi Dean, > > > > I have tried with -instr-map-1 and -instr-map-2, it didn't work. > > > > Yeah, I'm looking through the code and it looks like

Hi llvm-dev, I've been implementing a tool for analysing XRay traces. A recap of XRay's original RFC [0] mentions a tool that does function call accounting as a starting point. This is implemented currently in D21987 [1], and is being reviewed by David Blaikie. One key issue in that review is the dependency between the log format determined by the XRay runtime implementation in

Sent from my iPhone > On 6 Dec 2017, at 4:17 am, Brian Cain <brian.cain at gmail.com> wrote: > > > >> On Tue, Dec 5, 2017 at 9:49 AM, Dean Michael Berris via cfe-dev <cfe-dev at lists.llvm.org> wrote: >> Hi cfe-dev@ and llvm-dev@, >> >> I've attached a Chrome trace-viewer readable trace of a clang built with XRay instrumentation (additional

> On 20 Jul 2016, at 20:02, C Bergström <cbergstrom at pathscale.com> wrote: > > Some general questions about X-Ray > ------------- > Is there a plan to make a separate mailing list or project around > this? Do you have a list of planned features? Interesting question -- so far we haven't decided yet whether XRay will live as another project. I'm certainly open to

So I stumbled across an issue that I think is a bit fundamental: The xray runtime uses the C++ standard library. This seems like a problem because whatever C++ standard library is used to compile the XRay runtime may not be the same as the C++ standard library (if any) that is used to build the target application and link XRay into. Does this make sense? Is this a problem? Talking to Chandler

On Tue, Mar 14, 2017 at 5:34 PM Dean Michael Berris <dean.berris at gmail.com> wrote: > On 13 Mar 2017, at 15:39, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Sun, Mar 12, 2017, 4:10 PM Dean Michael Berris <dean.berris at gmail.com> > wrote: > > > > On 9 Mar 2017, at 09:32, David Blaikie via llvm-dev < > llvm-dev at

Hi llvm-dev, I've recently been working on improving the profiling mode for XRay in compiler-rt [0] and am ramping up efforts to do the same for flight-data recorder mode. The changes are generally in the direction of reducing the overheads (measured through benchmarks in the test-suite) and addressing some feature requests/bugs. In the interest of addressing these changes in a timely

> On 7 Sep 2016, at 01:21, David Blaikie <dblaikie at gmail.com> wrote: > > (sorry for the delay) > All good, thanks Dave! > On Tue, Aug 23, 2016 at 1:05 AM Dean Michael Berris <dean.berris at gmail.com <mailto:dean.berris at gmail.com>> wrote: > Hi llvm-dev, > > I've been implementing a tool for analysing XRay traces. A recap of XRay's