Displaying 20 results from an estimated 2000 matches similar to: "[XRay] Alternatives to relocations in .text section"
2017 Nov 21
2
question about xray tls data initialization
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 =
2017 Nov 23
2
question about xray tls data initialization
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
2017 Nov 16
2
question about xray tls data initialization
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 = [] {
2016 Jun 23
2
Building an array in a section from multiple object files
Hi,
As part of working on XRay, I'm trying to accomplish the following: create
a section that contains an array of entries pertaining to the
instrumentation map (nop sleds) in an object file, and have those merged
into a single section in the final binary where the contents are
concatenated. The trick though is I'd like to be able to reference the
whole array with a single symbol (or two,
2016 Jun 23
2
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
2016 Jun 27
0
Building an array in a section from multiple object files
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,
2019 Feb 02
2
[llvm-xray] llvm-xray cannot log every functions
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
2017 Jan 09
2
Removed a call to EmitXRayTable() from ARMAsmPrinter
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
2017 Jan 09
2
Removed a call to EmitXRayTable() from ARMAsmPrinter
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
2016 Jul 04
4
[XRay] RFC: LLVM-side Changes for nop-sleds
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 /
2016 Aug 05
2
XRay: Demo on x86_64/Linux almost done; some questions.
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
2016 Aug 23
2
[XRay][RFC] Tooling for XRay Trace Analysis
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
2016 Aug 04
2
XRay: Demo on x86_64/Linux almost done; some questions.
> 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,
2017 Jan 10
2
Removed a call to EmitXRayTable() from ARMAsmPrinter
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
2019 Jan 17
2
[RFC] Order File Instrumentation
On Thu, Jan 17, 2019 at 10:53 AM Xinliang David Li <davidxl at google.com>
wrote:
> Hi Manman,
>
> Ordering profiling is certainly something very useful to have to startup
> time performance. GCC has something similar.
>
> In terms of implementation, it is possible to simply extend the edge
> profiling counters by 1 for each function, and instrument the function to
>
2017 Oct 26
3
[RFC] Making .eh_frame more linker-friendly
Hi,
Many linkers including lld have a feature to eliminate unused sections from
output to make output smaller (which is essentially a mark-sweep gc where
sections are vertices and relocations are edges). lld and GNU gold have yet
another feature, ICF, to merge functions by contents to save more space.
When we remove or merge a function, we want to eliminate its exception
handling information as
2017 Oct 26
4
[RFC] Making .eh_frame more linker-friendly
No I haven't. Thank you for the pointer.
Looks like the problem of the inverted edges was discussed there. But I
guess my bigger question is this: why do we still create one big .eh_frame
even if -ffunction-sections is given?
When the option is given, Clang creates .text, .rela.text and
.gcc_exception_table sections for each function, but it still creates a
monolithic .eh_frame that covers
2016 Aug 08
2
XRay: Demo on x86_64/Linux almost done; some questions.
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
2019 Jan 17
2
[RFC] Order File Instrumentation
On Thu, Jan 17, 2019 at 2:47 PM Xinliang David Li <davidxl at google.com>
wrote:
>
>
> On Thu, Jan 17, 2019 at 2:32 PM Manman Ren <manman.ren at gmail.com> wrote:
>
>>
>>
>> On Thu, Jan 17, 2019 at 10:53 AM Xinliang David Li <davidxl at google.com>
>> wrote:
>>
>>> Hi Manman,
>>>
>>> Ordering profiling is
2016 Jun 27
1
Building an array in a section from multiple object files
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.