<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 9, 2017 at 5:01 PM Dean Michael Berris via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">dberris added inline comments.<br>
<br>
<br>
================<br>
Comment at: compiler-rt/trunk/lib/xray/xray_buffer_queue.h:45<br>
+  std::unique_ptr<std::tuple<Buffer, bool>[]> Buffers;<br>
+  size_t BufferCount;<br>
+<br>
----------------<br>
dblaikie wrote:<br>
> Shouldn't we be avoiding adding more standard library memory allocation to compiler-rt? (I thought that was one of the goals)<br>
><br>
> & 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?<br>
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?<br></blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D38119" rel="noreferrer" target="_blank">https://reviews.llvm.org/D38119</a><br>
<br>
<br>
<br>
</blockquote></div></div>