search for: fdr_log

...1 #include <thread> > 2 #include <tuple> > 1 #include <unordered_map> > 1 #include <unordered_set> > 3 #include <utility> > I think the biggest part is containers, and they are mostly > in ./xray_buffer_queue.h and ./xray_fdr_logging.cc. > > dependencies without buffer queue and fdr logging: > ...compiler-rt/lib/xray % grep '#include <[^>.]*>' -oh `find . -type > f|egrep -v 'tests|buffer|fdr'` | sort | uniq -c > 9 #include <atomic> > 4 #include <cassert> &gt...

So I stumbled across an issue that I think is a bit fundamental: The xray runtime uses the C++ standard library. 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. Does this make sense? Is this a problem? Talking to Chandler

...ad> > > 2 #include <tuple> > > 1 #include <unordered_map> > > 1 #include <unordered_set> > > 3 #include <utility> > > I think the biggest part is containers, and they are mostly in > ./xray_buffer_queue.h and ./xray_fdr_logging.cc. > > 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...