[PATCH] D38119: [XRay][compiler-rt] Use a hand-written circular buffer in BufferQueue

[David Blaikie via llvm-commits]

On Mon, Oct 9, 2017 at 5:01 PM Dean Michael Berris via Phabricator <
reviews at reviews.llvm.org> wrote:

> dberris added inline comments.
>
>
> ================
> Comment at: compiler-rt/trunk/lib/xray/xray_buffer_queue.h:45
> +  std::unique_ptr<std::tuple<Buffer, bool>[]> Buffers;
> +  size_t BufferCount;
> +
> ----------------
> dblaikie wrote:
> > Shouldn't we be avoiding adding more standard library memory allocation
> to compiler-rt? (I thought that was one of the goals)
> >
> > & that reminds me: I think the reason to avoid /all/ C++ standard
> library in compiler-rt is because of the possibility of mismatch between
> the standard library used to build compiler-rt and the one used to build
> user code. If theer is such a mismatch then the comdat functions will be
> chosen essentially at random and either the user code or the compiler-rt
> code using such a library function could end up quite broken. Right?
> What's the harm with using std::unique_ptr<T[]> here? That it will use the
> standard allocator? Is there an alternative, should we be using raw
> pointers instead? Should we be allocating it with new[] or with malloc
> directly?
>

I'm guessing maybe malloc directly - but I'd suggest having a chat/email
thread with the sanitizer folks to discuss the limitations/issues around
what rules they've used for their parts of compiler-rt, and why, to see
what parts are relevant to xray's users or not.


>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D38119
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171010/6f59f9c8/attachment.html>