search for: d21982

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

...onisation happens internally. Does this help? PS. I think more definitive documentation for this is due, let me think about putting something some documentation on how to use XRay as it is currently implemented once we have the naive in-memory logging implementation land (https://reviews.llvm.org/D21982). Cheers -- Dean

...unctionExit occurs at the > ; the exit of the function, even if it is being patched concurrently. Cool, thanks -- we have an interim logging implementation for x86 which does the naïve logging to memory then flushes to disk regularly (I suspect you've already seen https://reviews.llvm.org/D21982). In that patch we have the very early beginnings of a test suite, so I think if you'd like to contribute the ARM implementation, that we can review that patch and land it to allow you to add tests and make sure that this also works on ARM. I have zero experience with actually doing anything w...

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

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

...e > > ; the exit of the function, even if it is being patched concurrently. > > Cool, thanks -- we have an interim logging implementation for x86 which > does the naïve logging to memory then flushes to disk regularly (I suspect > you've already seen https://reviews.llvm.org/D21982). No, I wasn't aware of that patch, thanks for pointing out! > In that patch we have the very early beginnings of a test suite, so I > think if you'd like to contribute the ARM implementation, that we can > review that patch and land it to allow you to add tests and make sure tha...

...d cleanly to LLVM and compiler-rt allows for building applications with XRay tracing enabled on Linux binaries from start to end. The list of patches to apply are: * https://reviews.llvm.org/D21987 (accounting tool, lives in llvm) * https://reviews.llvm.org/D21612 then https://reviews.llvm.org/D21982 (compiler-rt XRay runtime implementation) To test this out, I built clang with XRay and ran it on a hello world application. Here's how I did it: 1) Build clang+compiler-rt with the above patches patched in. Follow the normal instructions for getting a version of clang (from trunk) built. I u...

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

...p? >> >> PS. I think more definitive documentation for this is due, let me think >> about putting something some documentation on how to use XRay as it is >> currently implemented once we have the naive in-memory logging >> implementation land (https://reviews.llvm.org/D21982). >> >> Cheers >> >> -- Dean >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160805/bc3f9f0b/attachment.html>

...e tool-specific internals testing. Is this something worth having? Any pointers on how to proceed with this unit-testing of tool-specific internals? Cheers -- Dean [0] http://lists.llvm.org/pipermail/llvm-dev/2016-April/098901.html [1] https://reviews.llvm.org/D21987 [2] https://reviews.llvm.org/D21982 [3] http://lists.llvm.org/pipermail/llvm-dev/2016-July/102552.html