search for: rogatch

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 the > tests compiler-rt\test\xray\Te...

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 tests. > The tests in compiler-rt had been accidentally disabled. > https...

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? > > On 26 January 2017 at 03:29, Serge Rogatch <serge.rogatch at gmail.com> wrote: >> >> Sorry,...

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. Without this map XR...

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

Sharing with the mailing list... Please, see below. On 9 January 2017 at 23:45, Serge Rogatch <serge.rogatch at gmail.com> wrote: > Hi Dean, > > I have seen that you removed the following code from ARMAsmPrinter.cpp in > revision 290858: > // Emit the XRay table for this function. > EmitXRayTable(); > > Was this done by mistake or on purpose? > > Wit...

> 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 > > // ass...

...config.host_arch.find('64') == -1: config.unsupported = True @Serge: You will need to change this condition to enable the tests for ARM. Oleg ________________________________________ From: Renato Golin <renato.golin at linaro.org> Sent: Monday, January 9, 2017 11:50 PM To: Serge Rogatch Cc: Dean Michael Berris; LLVM Developers; Oleg Ranevskyy Subject: Re: [llvm-dev] Removed a call to EmitXRayTable() from ARMAsmPrinter On 9 January 2017 at 20:47, Serge Rogatch via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Without this call, xray_instr_map gets empty in the execut...

...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 Aug 2016, at 23:27, Serge Rogatch <serge.rogatch at gmail.com> wrote: > > > > 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 > 1...

...on can be 32-bit too, right? So the entry can fit 16 bytes, with 10 useful bytes and 6 bytes of padding. Can I use 16-byte entries or is there some external (OS? ELF? Linker?) requirement that one entry must be 32-bytes, or aligned at 32 bytes, etc.? Thanks, Serge On 4 August 2016 at 19:29, Serge Rogatch <serge.rogatch at gmail.com> wrote: > Yes, double-checking on the handler side whether its resources are still > operational, e.g. by calling weak_ptr::lock() may be a better idea than > elimination of spurious handler calls in XRay at a cost of heavy > synchronization objects. O...

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

...(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 at 06:34, Dean Michael Berris <dean.berris at gmail.com> wrote: > > > On 6 Aug 2016, at 04:06, Serge Rogatch <serge.rogatch at gmail.com> wrote: > > > > 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 Addre...

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

...tor calling __xray_FunctionEntry and destructor calling __xray_FunctionExit ? Perhaps this approach requires changes in the front-end (C++ compiler, before emitting IR). Cheers. On 29 July 2016 at 21:00, Tim Northover <t.p.northover at gmail.com> wrote: > 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 u...

I don't object to backporting the fix. But I think the FDR itself is not in 4.0 yet. Let Dean suggest how risky FDR may be: I see substantial code changes, but for the old code they seem to be mostly moving. Dean, if you're on vacation, I can submit the compare_exchange_strong() fix. Cheers, Serge On 27 January 2017 at 19:52, Renato Golin <renato.golin at linaro.org> wrote: >

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 the > stack the address of __xray_Funct...

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

...t; >> @Serge: You will need to change this condition to enable the tests for ARM. >> >> Oleg >> >> ________________________________________ >> From: Renato Golin <renato.golin at linaro.org> >> Sent: Monday, January 9, 2017 11:50 PM >> To: Serge Rogatch >> Cc: Dean Michael Berris; LLVM Developers; Oleg Ranevskyy >> Subject: Re: [llvm-dev] Removed a call to EmitXRayTable() from ARMAsmPrinter >> >> On 9 January 2017 at 20:47, Serge Rogatch via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>>> Withou...

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 else instruction) rather than jumping into __xray_FunctionExit? By patching just the function entrances, you avoid

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