similar to: Building an array in a section from multiple object files

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

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,

Dean Michael Berris via llvm-dev <llvm-dev at lists.llvm.org> writes: > 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. In case you're not aware, the __start_/__stop_ trick isn't portable.

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

with some dirty hack , I've made xray runtime 'built' on windows , but unfortunately I haven't enough knowledge about linker and the runtime, and finally built executable didn't run. I'd like to share my changes here , hopes somebody help me to make it run on windows. in AsmPrinter, copy/paster xray for coff target InstMap =

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 /

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

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'm learning the xray library and try if it can be built on windows, in xray_fdr_logging_impl.h line 152 , comment written as // Using pthread_once(...) to initialize the thread-local data structures but at line 175, 183, code written as thread_local pthread_key_t key; // Ensure that we only actually ever do the pthread initialization once. thread_local bool UNUSED Unused = [] {

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

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

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

> 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 there, I have a problem using the function call tracing tools that is designed in llvm tools set. My aim is to record every function call that a program makes when it run. However, for whatever reason, a simple matrix multiply c program that I wrote cannot record all the function calls that happened when the program run. Here is the program: matrix.c #include <stdio.h> void

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

Hi I try to implement a coarse-grained CFI in LLVM (CFI = Contorl Flow Integrity) I want to collect all address after call instructions address after a call equals to a valid return site in coarse-grained CFI I want to add a new section and write all the possible return address in the new section (and then, add the integrity check) I have some quetions: (1) Which part of LLVM code should

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

Hi llvm-dev, I've been implementing a tool for analysing XRay traces. A recap of XRay's original RFC [0] mentions a tool that does function call accounting as a starting point. This is implemented currently in D21987 [1], and is being reviewed by David Blaikie. One key issue in that review is the dependency between the log format determined by the XRay runtime implementation in

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.

Why there are no tests that would break in this case? On Mon, Jan 9, 2017 at 8:32 PM, Dean Michael Berris via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Oops -- sorry about that, this is definitely unintended. Adding in Martin who made the change. > > I'm happy to review changes to fix this, or if you don't get to it first I can drive by that part of the code and try