Displaying 3 results from an estimated 3 matches for "xraysledentri".
Did you mean:
xraysledentry
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 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,
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