similar to: XRay Trace of Clang, Loadable through Chrome Trace Viewer

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

Hi all, I was interested in trying out the Xray profiling component in LLVM and was trying to compile a C program with Clang with Xray flags. Unfortunately, I keep getting a linker error everytime I try to compile the C program with Clang. However, the error goes away when I try to compile the same C program with Clang++ with -xc++ flag. Searching around for this issue, looks like somebody has

Hi everyone, TL;DR: With current pending patches applied in compiler-rt and llvm, and trunk clang, you can build your application with XRay tracing enabled on Linux with tracing enabled before main starts, and logging stops when the main thread exits. Just a quick update, I have some patches under review that when applied cleanly to LLVM and compiler-rt allows for building applications with XRay

Hi all, I want to test X-ray performance and compare it with other research tools, so I use Clang 7.0.0 to compile and instrument GNU binutils-2.3.1 with the following commands: cd binutils-2.31/ mkdir build cd build/ CC=$local/clang CXX=$local/clang++ CFLAGS=-fxray-instrument CXXFLAGS=-fxray-instrument ../configure --prefix=/home/zhangysh1995/local make Then I extract instrumentation map

Hi there, I have a problem using the function call tracing tools that is designed in llvm tools set. My aim is to record every function call that a program makes when it run. However, for whatever reason, a simple matrix multiply c program that I wrote cannot record all the function calls that happened when the program run. Here is the program: matrix.c #include <stdio.h> void

Hi Dean, I've noticed that XRay in llvm\lib\CodeGen\XRayInstrumentation.cpp compares its threshold against Function::size() . However, Function::size() returns the number of basic blocks (as I understand, such as cycle bodies, if/else bodies, switch-case bodies, etc.), rather than the number of instructions. Was your intent to count the instructions instead? The name of the parameter

Hi All, I am trying to test run clang XRay tool. I was following the steps at [1]. But the log file does not seem to get generated. According to the instructions I used 'fxray-instrument' switch when compiling and then specified 'patch_premain=true' at XRAY_OPTIONS. Is there anything else that I need to do? I am on a trunk build of clang. Could that be it? I am on clang version

Hi, The following three patches, when applied cleanly to LLVM+Clang+compiler-rt will now allow for building and running binaries with a very simple version of XRay included: http://reviews.llvm.org/D21612 (compiler-rt) http://reviews.llvm.org/D20352 (clang) http://reviews.llvm.org/D19904 (llvm) To use this on x86_64-unknown-linux-gnu you'd need to set the flags '-fxray-instrument'

Thanks Nirav, I can confirm that this works when I do the compile with llc, but then when linking to an executable with clang (patched with http://reviews.llvm.org/D20352 and compiler-rt patched with http://reviews.llvm.org/D21612) on Linux, I'm getting something different. Here's a sample of the transcript, and what I'm seeing: --->8 clang invocation 8<--- [16-06-23 3:33:42]

TL;DR: At Google we use a call tracing system called XRay which inserts patchable instrumentation points into function entries and exits. If the community is interested, we'd like to contribute this system to the LLVM project. Many more details are contained in the whitepaper at: https://storage.googleapis.com/xray-downloads/whitepaper/XRayAFunctionCallTracingSystem.pdf Who's

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

On Fri, Jun 17, 2016 at 5:42 AM Matthias Braun via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Some of this overlaps with the features in XRay ( > http://lists.llvm.org/pipermail/llvm-dev/2016-April/098901.html). > > Matthias beat me to it! >From reading the RFC, it seems that some of what XRay is doing on the instrumentation side is very similar to what CSI enables. The

> 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

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

> 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

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

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

Hmm. Odd. I just rebuilt from scratch and it seems to work with the test/CodeGen/X86/xray-attribute-instrumentation.ll test case outputing straight to obj: llc -filetype=obj -o ~/a.o -mtriple=x86_64-apple-macosx < test/CodeGen/X86/xray-attribute-instrumentation.ll What test case are you using? In any case, the issue appears to be that llvm doesn't realize that the target address is

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