similar to: XRay threshold (bug?)

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

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.

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

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

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

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

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

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

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 Renato, As far as I understand, such issues should be caught by the tests in compiler-rt/test/xray/TestCases/Linux. I found the following lines in compiler-rt/test/xray/lit.cfg that seem to disable the tests for non-64-bit targets: if config.host_os not in ['Linux'] or config.host_arch.find('64') == -1: config.unsupported = True @Serge: You will need to change this

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

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

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

+Dean Michael Berris <dberris at google.com> On Wed, Jan 25, 2017 at 7:01 AM Oleg Ranevskyy via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Renato, Dean, Serge, > > Just looked into the code and wanted to share some thoughts. > > This might be a compare_exchange_weak spurious failure. ARM is a weakly > ordered CPU, but I am not sure whether spurious failures

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)

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

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