similar to: XRay: Demo on x86_64/Linux almost done; some questions.

> 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

On 29 July 2016 at 10:43, Dean Michael Berris <dean.berris at gmail.com> wrote: > > > 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

Thanks for pointing this out, Tim. Then maybe this approach is not the best choice for x86, though ideally measuring is needed, it is just that on ARM the current x86 approach is not applicable because ARM doesn't have a single return instruction (such as RETQ on x86_64), furthermore, the return instructions on ARM can be conditional. I have another question: what happens if the instrumented

On 28 July 2016 at 16:14, Serge Rogatch via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 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 else instruction)

> On 30 Jul 2016, at 05:07, Serge Rogatch via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thanks for pointing this out, Tim. Then maybe this approach is not the best choice for x86, though ideally measuring is needed, it is just that on ARM the current x86 approach is not applicable because ARM doesn't have a single return instruction (such as RETQ on x86_64), furthermore,

> On 4 Aug 2016, at 06:27, Serge Rogatch <serge.rogatch at gmail.com> wrote: > > Hi Dean, > > I have a question about the following piece of code in compiler-rt/trunk/lib/xray/xray_trampoline_x86.S : > movq _ZN6__xray19XRayPatchedFunctionE(%rip), %rax > testq %rax, %rax > je .Ltmp0 > > // assume that %r10d has the function id. > movl %r10d,

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.

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

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

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

I think that 32-bit systems (especially ARM) may be short on memory so doubling the size of the table containing (potentially) all the functions may give a tangible overhead. I would even align the entries to 4 bytes (so 12 bytes per entry) on 32-bit platforms and to 8 bytes (so 24-bytes per entry) on 64-bit platforms, to improve CPU cache hits. What do you think? Cheers, Serge On 8 August 2016

On 26 January 2017 at 20:04, Serge Rogatch <serge.rogatch at gmail.com> wrote: > Thank you for considering. > Dean, Renato - what do you think? Hi, sorry it took so long. Yes, those two patches are fundamental to make XRay work on ARM. Backporting makes sense. We already added XRay on both ARM and AArch64 release notes, so they have to work. :) --renato

Hi Dean, Do you have any estimates on when https://reviews.llvm.org/D21982 will reach mainline? (As I understood it's not yet there, looking at http://llvm.org/svn/llvm-project/compiler-rt/trunk ). I would like to test ARM port of XRay, so ready logging would be handful. Thanks, Serge On 8 August 2016 at 17:41, Dean Michael Berris <dean.berris at gmail.com> wrote: > > > On 8

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 llvm-dev (cc google-xray), As a follow-up to the first XRay RFC [0] introducing the technology, I've been able to recently implement a functional prototype of the major parts of the XRay functionality [1]. This RFC is limited to exploring potential alternatives to the current LLVM-side changes, with the interest of getting clear guidance for landing the changes first in LLVM. Background /

Yes, I will, just a little later today. On 30 January 2017 at 15:25, Renato Golin <renato.golin at linaro.org> wrote: > On 29 January 2017 at 18:32, Renato Golin <renato.golin at linaro.org> wrote: > > FYI, we got it again... > > > > http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/3875 > > > > So it wasn't a one of. > >

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

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

On Wed, Nov 22, 2017 at 10:37 AM, Dean Michael Berris <dean.berris at gmail.com> wrote: > > On 22 Nov 2017, at 02:32, comic fans <comicfans44 at gmail.com> wrote: > > with some dirty hack , I've made xray runtime 'built' on windows , > > > \o/ with more test, I've found that trampoline didn't got built for windows :/ currently cmake didn't