similar to: [XRay] Build instrumented Clang, some analysis results

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

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

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]

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'

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

Hello everyone! After I've checked out Clang and Compiler-RT repositories, I receive this error during compilation: llvm[5]: Compiling PathDiagnostic.cpp for Debug+Asserts build /media/data/dev/llvm/llvm/tools/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp: In member function 'bool {anonymous}::CompareDiagnostics::operator()(const clang::ento::PathDiagnostic*, const

Hi Vadim, which compiler are you using to to the build, what platform are you on, how did you configure LLVM, clang etc ? Ciao, duncan. On 09/09/12 03:36, Vadim Khoptynets wrote: > Hello everyone! > > After I've checked out Clang and Compiler-RT repositories, I receive this error > during compilation: > > llvm[5]: Compiling PathDiagnostic.cpp for Debug+Asserts build >

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

While attempting to reduce a ubsan-specific bug, I stumbled upon the following. [I would have filed a bug report, but don't have an account, and so requested one per https://bugs.llvm.org/ about 7 hours ago -- but still no response, so am sending this instead. ] Using clang built from latest master of about 5 hours ago: $ echo struct a typename a | clang -x c++ - <stdin>:1:19: error:

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

Adding cfe-dev, since this is a clang issue. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Jim Meyering via llvm-dev <llvm-dev at lists.llvm.org> Reply-To: Jim Meyering <jim at meyering.net> Date: Monday, April 2, 2018 at 8:40 PM To: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org> Subject: [llvm-dev] trivial input provokes failed

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

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

Peter suggested just writing out '.byte 0xeb, 0x09' and that allowed the jump instruction to bypass the relaxation, so that fixes my immediate problem. The question still stands though whether it should be possible to do through the instruction builder interface. Cheers On Wed, Jun 22, 2016 at 10:40 AM Dean Michael Berris <dberris at google.com> wrote: > Thanks Nirav, > >

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