similar to: [XRay] RFC: LLVM-side Changes for nop-sleds

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

Sorry, I initially included LLVM-Commits rather than LLVM-Dev. Fixed. On 26 January 2017 at 03:26, Serge Rogatch <serge.rogatch at gmail.com> wrote: > Hi Dean, Renato, > > AFAIK, unfortunately, these critical Arm32 XRay fixes are not yet in 4.0: > https://reviews.llvm.org/D28624 , https://reviews.llvm.org/D28623 . The > first repairs XRay instrumentation map emission.

Hi, As part of working on XRay, I'm trying to accomplish the following: create a section that contains an array of entries pertaining to the instrumentation map (nop sleds) in an object file, and have those merged into a single section in the final binary where the contents are concatenated. The trick though is I'd like to be able to reference the whole array with a single symbol (or two,

How is XRay tested? IIRC, Renato didn't see any test failures on ARM? Merging sounds reasonbaly, I'd just like to understand what's the risk for the branch. On Thu, Jan 26, 2017 at 10:29 AM, Serge Rogatch <serge.rogatch at gmail.com> wrote: > Hans, these changes reached trunk in https://reviews.llvm.org/rL292516 and > https://reviews.llvm.org/rL292517 . Could you look?

I'm wondering why the lit tests didn't catch this as part of testing rc1 on ARM. On Thu, Jan 26, 2017 at 11:25 AM, Serge Rogatch <serge.rogatch at gmail.com> wrote: > XRay is tested automatically on build-bots with tests in LLVM and > compiler-rt . Or are you asking for manual testing instructions? > Of these 2 patches, the compiler-rt patch depends on LLVM patch because

Awesome, thanks Peter! Cheers On Thu, Jun 23, 2016 at 10:35 AM Peter Collingbourne <peter at pcc.me.uk> wrote: > If you give your section a valid C identifier name, i.e. something like > "xray_instr_map" (no period), the linker will synthesize symbols named > "__start_xray_instr_map" and "__stop_xray_instr_map", which will point to > the start and

I see. Thanks for clarifying. I'm Ok with merging these if Dean agrees, as I believe he's the code owner. Thanks, Hans On Thu, Jan 26, 2017 at 11:47 AM, Serge Rogatch <serge.rogatch at gmail.com> wrote: > There were no LLVM tests for presence of XRay instrumentation map in the > emitted assembly. You can see that https://reviews.llvm.org/D28624 adds this > check to the

> 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

Hi Dean, I have a question for 32-bit platforms. I see in the code that you used the following in compiler-rt/trunk/lib/xray/xray_interface_internal.h : struct XRaySledEntry { uint64_t Address; uint64_t Function; unsigned char Kind; unsigned char AlwaysInstrument; unsigned char Padding[14]; // Need 32 bytes }; And the peer code in llvm/trunk/lib/Target/X86/X86MCInstLower.cpp : void

On Fri, Jan 18, 2019 at 3:56 PM Manman Ren <manman.ren at gmail.com> wrote: > Some background information first, then a quick summary of what we have > discussed so far! > > Background: Facebook app is one of the biggest iOS apps. Because of this, > we want the instrumentation to be as lightweight as possible in terms of > binary size, profile data size, and runtime

Hi llvm-dev, I'm currently looking for alternatives to the synthetic references that XRay uses to keep some side-tables live, to avoid linker garbage collection from deleting those sections. Before going any further, let me give a backgrounder on what XRay does today. Background ========== XRay has two side tables we use at runtime to identify the location of the sleds for the functions

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

Just to close this out, I've updated http://reviews.llvm.org/D19904 to use named ELF groups per-function, and have the runtime library use __start_xray_instr_map and __stop_xray_instr_map as weak symbols from the C++ side. I've sent a patch to make creating these COMDAT/Group sections easier when lowering through the MCStreamer interface ( http://reviews.llvm.org/D21743). Cheers On Fri,

On Thu, Jan 17, 2019 at 10:53 AM Xinliang David Li <davidxl at google.com> wrote: > Hi Manman, > > Ordering profiling is certainly something very useful to have to startup > time performance. GCC has something similar. > > In terms of implementation, it is possible to simply extend the edge > profiling counters by 1 for each function, and instrument the function to >

On Fri, Jan 18, 2019 at 9:10 PM Manman Ren <manman.ren at gmail.com> wrote: > > > On Fri, Jan 18, 2019 at 4:11 PM Xinliang David Li <davidxl at google.com> > wrote: > >> >> >> On Fri, Jan 18, 2019 at 3:56 PM Manman Ren <manman.ren at gmail.com> wrote: >> >>> Some background information first, then a quick summary of what we have

On Thu, Jan 17, 2019 at 2:47 PM Xinliang David Li <davidxl at google.com> wrote: > > > On Thu, Jan 17, 2019 at 2:32 PM Manman Ren <manman.ren at gmail.com> wrote: > >> >> >> On Thu, Jan 17, 2019 at 10:53 AM Xinliang David Li <davidxl at google.com> >> wrote: >> >>> Hi Manman, >>> >>> Ordering profiling is

> On 29 Jul 2016, at 09:14, Serge Rogatch via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > Can I ask you why you chose to patch both function entrances and exits, rather than just patching the entrances and (in the patches) pushing on the stack the address of __xray_FunctionExit , so that the user function returns normally (with RETQ or POP RIP or whatever

Order file is used to teach ld64 how to order the functions in a binary. If we put all functions executed during startup together in the right order, we will greatly reduce the page faults during startup. To generate order file for iOS apps, we usually use dtrace, but some apps have various startup scenarios that we want to capture in the order file. dtrace approach is not easy to automate, it is

I would love to see this kind of order profiling support. Using dtrace to generate function orders is actually really problematic because dtrace made tradeoffs in implementation allowing it to ignore probe execution if the performance impact is too great on the system. This can result in dtrace being non-deterministic which is not ideal for generating optimization data. Additionally if order

On Mon, Jun 27, 2016 at 2:53 PM Xinliang David Li <davidxl at google.com> wrote: > There is some misunderstanding about the intention of this flag. The > purpose of the flag is not to turn on profile instrumentation (which > already has -fprofile-instr-generate or -fprofile-generate for it), but to > select which instrumentors to use for PGO (IR or FE). I prefer fewer flags