<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 8, 2017 at 2:28 PM Tim Shen <<a href="mailto:timshen@google.com">timshen@google.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"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Wed, Mar 8, 2017 at 1:49 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" class="gmail_msg" target="_blank">dblaikie@gmail.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" 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 class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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><div><br></div><div>Not sure - Evgeniy (cc'd) might know. Partly perhaps the development cost of having to isolate that statically linked library from colliding with any other (some kind of mangling scheme would have to be used, I think? to avoid such a collision).</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"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" 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 class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">I believe that "state-side" is LLVM team side?</div></div></div></blockquote><div><br>Right, yes, sorry.<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"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> I agree that we should clean up the standard library usage even just for consistency.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Searching the xray directory for dependencies:</div><div class="gmail_msg"><div class="gmail_msg">...compiler-rt/lib/xray % grep '#include <[^>.]*>' -oh `find . -type f|grep -v 'tests'` | sort | uniq -c</div><div class="gmail_msg"> 1 #include <algorithm></div><div class="gmail_msg"> 10 #include <atomic></div><div class="gmail_msg"> 1 #include <bitset></div><div class="gmail_msg"> 6 #include <cassert></div><div class="gmail_msg"> 1 #include <cerrno></div><div class="gmail_msg"> 1 #include <cstddef></div><div class="gmail_msg"> 7 #include <cstdint></div><div class="gmail_msg"> 2 #include <cstdio></div><div class="gmail_msg"> 1 #include <cstdlib></div><div class="gmail_msg"> 2 #include <cstring></div><div class="gmail_msg"> 1 #include <deque></div><div class="gmail_msg"> 2 #include <iterator></div><div class="gmail_msg"> 2 #include <limits></div><div class="gmail_msg"> 2 #include <memory></div><div class="gmail_msg"> 4 #include <mutex></div><div class="gmail_msg"> 1 #include <system_error></div><div class="gmail_msg"> 1 #include <thread></div><div class="gmail_msg"> 2 #include <tuple></div><div class="gmail_msg"> 1 #include <unordered_map></div><div class="gmail_msg"> 1 #include <unordered_set></div><div class="gmail_msg"> 3 #include <utility></div></div><div class="gmail_msg">I think the biggest part is containers, and they are mostly in ./xray_buffer_queue.h and ./xray_fdr_logging.cc.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">dependencies without buffer queue and fdr logging:</div><div class="gmail_msg"><div class="gmail_msg">...compiler-rt/lib/xray % grep '#include <[^>.]*>' -oh `find . -type f|egrep -v 'tests|buffer|fdr'` | sort | uniq -c</div><div class="gmail_msg"> 9 #include <atomic></div><div class="gmail_msg"> 4 #include <cassert></div><div class="gmail_msg"> 1 #include <cerrno></div><div class="gmail_msg"> 1 #include <cstddef></div><div class="gmail_msg"> 6 #include <cstdint></div><div class="gmail_msg"> 2 #include <cstdio></div><div class="gmail_msg"> 1 #include <cstring></div><div class="gmail_msg"> 2 #include <iterator></div><div class="gmail_msg"> 2 #include <limits></div><div class="gmail_msg"> 1 #include <memory></div><div class="gmail_msg"> 3 #include <mutex></div><div class="gmail_msg"> 1 #include <thread></div><div class="gmail_msg"> 2 #include <tuple></div><div class="gmail_msg"> 2 #include <utility></div></div><div class="gmail_msg">I believe that this is relatively easy to cleanup. I can do that.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I don't know how hard it is to rewrite buffer queue and fdr logging using compiler_rt infrastructure.</div></div></div></blockquote><div><br>I think buffer_queue's probably sufficiently well bounded that it shouldn't be drastically hard to replace it with a custom implementation. Haven't looked at fdr_logging.<br><br>Maps/dictionary-like things might be a bit of a pain in particular. Not sure if the sanitizers already have some reusable idioms/libraries for that.<br><br>I'm also not really clear on where the boundary is - which headers or language features ('new'?) can be used, and which can't. Can't say I've ever tried to make code library agnostic.<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"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" 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></blockquote></div></div>