[llvm-dev] XRay: Demo on x86_64/Linux almost done; some questions.

[Serge Rogatch via llvm-dev]

Yes, double-checking on the handler side whether its resources are still
operational, e.g. by calling weak_ptr::lock() may be a better idea than
elimination of spurious handler calls in XRay at a cost of heavy
synchronization objects. Ok, let's live with spurious handler calls.

Cheers,
Serge

On 4 August 2016 at 10:57, Dean Michael Berris <dean.berris at gmail.com>
wrote:

>
> > 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, %edi
> >   xor  %esi,%esi
> >   callq  *%rax
> > What happens if someone unsets the handler function (i.e. calls
> __xray_remove_handler() ) or changes the handler (i.e. calls
> __xray_set_handler() with a different pointer to function) between "movq
> _ZN6__xray19XRayPatchedFunctionE(%rip), %rax" and "callq  *%rax" ? I
> understood that the old handler will still be called, but isn't it a
> problem? What if the code removing the handler starts destructing some
> objects after that, so that a handler call would result in a crash or other
> bad things?
>
> That would be unfortunate. :)
>
> Yes, you're right, it will be called despite having the handler be un-set
> from the global atomic. Though I'd suggest that log handler implementations
> really shouldn't be crashing, and should assume that it will be called at
> any given time (from multiple threads, so it should also be thread-safe).
> Consider also that we're taking a function pointer by design -- assuming
> that it will be a pointer to a function that will only deal with globals
> and the explicitly passed in arguments.
>
> An implementer of the log handler should really be responsible for
> "internal signalling" -- i.e. implementing it so that any required
> synchronisation 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160804/657ad566/attachment.html>