similar to: RFC: XRay FDR/Profiling Mode Moving to Post-Commit Review

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

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

# 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 application. # Background XRay has two modes currently implemented in compiler-rt: a basic (nee naive) mode and flight data recorder (FDR) mode. Basic mode logging, when enabled, will collect

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 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

Yeah, I was being optimistic about this one. It should be changed to strong if he weak version doesn't quite do it. The other way to do this is to change the test to do the polling, but that seems sub-optimal. Sent from my iPhone > On 26 Jan 2017, at 5:10 am, Serge Rogatch via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > Indeed, it seems that exactly this

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

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

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

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>

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

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

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

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

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

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

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 Dean, I have tried with -instr-map-1 and -instr-map-2, it didn't work. Is there a way to find the function name from the identifier? -DTharun On Mon, Jan 7, 2019 at 2:29 PM Dean Michael Berris <dean.berris at gmail.com> wrote: > Hi Dangeti, > > That's interesting -- can you try providing both `-instr-map-1=` and > `-instr-map-2=` even though they're the same

> 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

Hi, The call graphs generated by "*llvm-xray graph*" has function names, while the "*llvm-xray graph-diff*" doesn't shows function names. This is the command I am using llvm-xray graph-diff xray-log.clang.1 xray-log.clang.2 -instr-map=../xray-build/bin/clang -o diff.dot Attached is the portion of the generated diff graph. Am I missing any flag? [image: graph_diff.jpg]