similar to: [X-ray] How to check successful instrumentation and generate call trace?

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 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 all, I am trying to add XRay support to the IR produced by GHC. Getting the basics working is not too complicated after adding the right function attribute but any analysis shows the function names but not the locations of the functions. In particular, I run a program which has been instrumented as follows: XRAY_OPTIONS="patch_premain=true xray_mode=xray-basic verbosity=1" ./llvm

> On 3 Dec 2018, at 23:01, Matthew Pickering via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Is anyone able to help me with this or suggest where I might be able > to get help? You’ve asked the right place, apologies for the delay I’m supposed to be answering these questions. > > Matt > On Mon, Nov 26, 2018 at 3:02 PM Matthew Pickering > <matthewtpickering

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 David, Sorry for taking a few days to reply. It's not easy for you to compile a Haskell file to see the problem as the debug information is still WIP. Below I prove the IR for a simple hello world program which you can feed into llc. https://gist.github.com/05296933e37e87533a51d493b46aa48d The `out.ir` file can be passed straight to `llc`. Can you see anything obviously wrong? Matt

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

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

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

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

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

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]

On Wed, Jun 22, 2016 at 6:05 AM Nirav Davé <niravd at google.com> wrote: > This appears to work: > > auto Target = OutContext.createLinkerPrivateTempSymbol(); > > with > > auto Target = OutContext.createTempSymbol(); > > -Nirav > > Thanks Nirav -- I tried this but I'm still getting a "jmpq <address>" with this incantation when I load and

No, I don't. But I’m sure it is not optimized because I can see this variable in the final binary file emitted. Do you mean if I don’t refer to this variable in the front end, then I can’t see it in the backend? (although it’s in the final binary file) Thank you! 2019年1月19日(土) 2:00 <paul.robinson at sony.com>: > Do you have a use of the new variable as well? If not, it might be

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

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

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