<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Mar 8, 2017 at 1:49 PM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">So I stumbled across an issue that I think is a bit fundamental:<br class="gmail_msg"><br class="gmail_msg">The xray runtime uses the C++ standard library.<br class="gmail_msg"><br class="gmail_msg">This seems like a problem because whatever C++ standard library is used to compile the XRay runtime may not be the same as the C++ standard library (if any) that is used to build the target application and link XRay into.<br class="gmail_msg"><br class="gmail_msg">Does this make sense? Is this a problem?<br class="gmail_msg"><br class="gmail_msg">Talking to Chandler over lunch it sounds like there's a couple of options - either remove the dependency (much like, I believe, the sanitizer runtimes - use nothing from the C++ standard library, replace everything with custom data structures, etc) or, perhaps more drastically, change the way the runtimes are built such that they statically link a private version of, say, libc++.<br class="gmail_msg"></div></blockquote><div><br></div><div>What's the reason of not static-linking a C++ standard library for sanitizer runtimes back to when it was created?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><br class="gmail_msg">Chandler seemed to think maybe we could do this state-side (Tim? Might be something you could handle) rather than pushing it back on to Dean, if that sounds reasonable?<br class="gmail_msg"></div></blockquote><div><br></div><div>I believe that "state-side" is LLVM team side? I agree that we should clean up the standard library usage even just for consistency.</div><div><br></div><div>Searching the xray directory for dependencies:</div><div><div>...compiler-rt/lib/xray % grep '#include <[^>.]*>' -oh `find . -type f|grep -v 'tests'` | sort | uniq -c</div><div> 1 #include <algorithm></div><div> 10 #include <atomic></div><div> 1 #include <bitset></div><div> 6 #include <cassert></div><div> 1 #include <cerrno></div><div> 1 #include <cstddef></div><div> 7 #include <cstdint></div><div> 2 #include <cstdio></div><div> 1 #include <cstdlib></div><div> 2 #include <cstring></div><div> 1 #include <deque></div><div> 2 #include <iterator></div><div> 2 #include <limits></div><div> 2 #include <memory></div><div> 4 #include <mutex></div><div> 1 #include <system_error></div><div> 1 #include <thread></div><div> 2 #include <tuple></div><div> 1 #include <unordered_map></div><div> 1 #include <unordered_set></div><div> 3 #include <utility></div></div><div>I think the biggest part is containers, and they are mostly in ./xray_buffer_queue.h and ./xray_fdr_logging.cc.</div><div><br></div><div>dependencies without buffer queue and fdr logging:</div><div><div>...compiler-rt/lib/xray % grep '#include <[^>.]*>' -oh `find . -type f|egrep -v 'tests|buffer|fdr'` | sort | uniq -c</div><div> 9 #include <atomic></div><div> 4 #include <cassert></div><div> 1 #include <cerrno></div><div> 1 #include <cstddef></div><div> 6 #include <cstdint></div><div> 2 #include <cstdio></div><div> 1 #include <cstring></div><div> 2 #include <iterator></div><div> 2 #include <limits></div><div> 1 #include <memory></div><div> 3 #include <mutex></div><div> 1 #include <thread></div><div> 2 #include <tuple></div><div> 2 #include <utility></div></div><div>I believe that this is relatively easy to cleanup. I can do that.</div><div><br></div><div>I don't know how hard it is to rewrite buffer queue and fdr logging using compiler_rt infrastructure.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><br class="gmail_msg">(this came up for me due to what's probably a bug in the way compiler-rt is built - where the lib itself is built with the host compiler but the tests are built/linked with the just-bulit clang. My host compiler uses libstdc++ 6, whereas the just-built clang will use libstdc++ 4.8. So it fails to link due to this mismatch)</div>
</blockquote></div></div>