<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 15 Mar 2017, at 12:19, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Verdana; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Mar 14, 2017 at 5:34 PM Dean Michael Berris <<a href="mailto:dean.berris@gmail.com" class="">dean.berris@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="gmail_msg" style="word-wrap: break-word;"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 13 Mar 2017, at 15:39, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="gmail_msg" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br class="gmail_msg m_-7049078823084148896Apple-interchange-newline"><div class="gmail_msg"><br class="gmail_msg" style="font-family: Verdana; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><br class="gmail_msg" style="font-family: Verdana; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div class="gmail_quote gmail_msg" style="font-family: Verdana; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div dir="ltr" class="gmail_msg">On Sun, Mar 12, 2017, 4:10 PM Dean Michael Berris <<a href="mailto:dean.berris@gmail.com" class="gmail_msg" target="_blank">dean.berris@gmail.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><br class="gmail_msg">> On 9 Mar 2017, at 09:32, David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg">><br class="gmail_msg">> I agree that we should clean up the standard library usage even just for consistency.<br class="gmail_msg">><br class="gmail_msg"><br class="gmail_msg">+1 -- now that I think about it, it should be fairly doable (also happy to help with reviews if that helps).<br class="gmail_msg"><br class="gmail_msg">> Searching the xray directory for dependencies:<br class="gmail_msg">> ...compiler-rt/lib/xray % grep '#include <[^>.]*>' -oh `find . -type f|grep -v 'tests'` | sort | uniq -c<br class="gmail_msg">>       1 #include <algorithm><br class="gmail_msg">>      10 #include <atomic><br class="gmail_msg">>       1 #include <bitset><br class="gmail_msg">>       6 #include <cassert><br class="gmail_msg">>       1 #include <cerrno><br class="gmail_msg">>       1 #include <cstddef><br class="gmail_msg">>       7 #include <cstdint><br class="gmail_msg">>       2 #include <cstdio><br class="gmail_msg">>       1 #include <cstdlib><br class="gmail_msg">>       2 #include <cstring><br class="gmail_msg">>       1 #include <deque><br class="gmail_msg">>       2 #include <iterator><br class="gmail_msg">>       2 #include <limits><br class="gmail_msg">>       2 #include <memory><br class="gmail_msg">>       4 #include <mutex><br class="gmail_msg">>       1 #include <system_error><br class="gmail_msg">>       1 #include <thread><br class="gmail_msg">>       2 #include <tuple><br class="gmail_msg">>       1 #include <unordered_map><br class="gmail_msg">>       1 #include <unordered_set><br class="gmail_msg">>       3 #include <utility><br class="gmail_msg">> I think the biggest part is containers, and they are mostly in ./xray_buffer_queue.h and ./xray_fdr_logging.cc.<br class="gmail_msg"><br class="gmail_msg">Yes, buffer_queue can definitely live without using system_error, unordered_map, and unordered_set. It might make it a bit more complex (we'd need to implement a correct and fairly efficient hash set) but if it means the deployment model is simpler then I'm happy with that trade-off. When we were implementing this, we made a decision to make it so that the "mismatch of standard library implementations" was treated as a lower priority issue -- something we don't think comes up as often, and is easily solvable by re-building the runtime with the standard library the end application/binary will be using anyway. Since XRay is only ever statically-linked (we don't have a dynamic version of it), I thought the rebuild option is slightly simpler than trying to implement the whole XRay runtime in a constrained version of C++ and libc-only functions.<br class="gmail_msg"></blockquote></div><div class="gmail_msg" style="font-family: Verdana; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><br class="gmail_msg"></div><div class="gmail_msg" style="font-family: Verdana; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">Except that's not how llvm is distributed. In releases it will ship with the compiler and runtime libraries but can be used with any c++ standard library.</div><div class="gmail_msg" style="font-family: Verdana; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><br class="gmail_msg"></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div class="gmail_msg" style="word-wrap: break-word;"><div class="gmail_msg"><div class="gmail_msg">That's fair. I was mostly thinking of the majority cases where I assumed that the user would be using clang/llvm/compiler-rt with the system-provided standard library anyway, and any exotic set-ups (not system libraries used) would require more work from the user anyway.</div></div></div></blockquote><div class=""><br class="">Not much work - Clang discovers existing GCC installations and picks the newest. So at the very least, if a user installs a newer GCC, they get a newer libstdc++ and Clang implicitly picks that up without any further work.<br class=""><br class="">Also Clang distribution might be available for several platforms which may have different system compilers/std libraries, the distribution is statically linked - so libstdc++ doesn't have to match or be present on the destination system, I think?<br class=""> </div></div></div></div></blockquote><div><br class=""></div><div>Ah, for *binary* distributions of LLVM/compiler-rt, then yes this would be bad.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Verdana; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="gmail_msg" style="word-wrap: break-word;"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg" style="font-family: Verdana; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">This isn't a quality if implementation thing, this is more a correctness issue.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div class="gmail_msg" style="word-wrap: break-word;"><div class="gmail_msg"><div class="gmail_msg">I'm less convinced of that, mostly because I've assumed that users using libraries and runtimes will be aware of the potential ABI incompatibilities that arise when using different standard libraries to build and then link.</div></div></div></blockquote><div class=""><br class="">But they won't be aware that they're mismatched - they take the LLVM distribution, compile their code on a system with a libstdc++ different from the one on the system where the LLVM distribution was built... and badness.<br class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="gmail_msg" style="word-wrap: break-word;"><div class="gmail_msg"><div class="gmail_msg">But if the constraints are different for runtimes in compiler-rt, then I'm alright with abiding by those. :)</div></div></div></blockquote><div class=""><br class="">*nod* so far as I know, the runtimes have historically not depended on libstdc++ for these reasons (& the added bonus that the sanitizers need to sit below such libraries)<br class=""> </div></div></div></div></blockquote><div><br class=""></div><div>SGTM. I'll add this to the list of priorities we have for tracking.</div><div><br class=""></div><div>Probably worth filing a bug on <a href="http://bugs.llvm.org" class="">bugs.llvm.org</a> too, against XRay runtime assigned to me. :)</div><div><br class=""></div><div>Cheers</div></div><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">-- Dean</div></div>

</div>
<br class=""></body></html>