Le 13 août 2013 à 01:25, Nick Lewycky <[email protected]> a écrit :
> The attached patch causes ubsan to get linked in when building a .so file. > This is different from other sanitizers. > > The other sanitizers are harder to deploy because they rely on replacing > malloc. This means that you have to figure out how to link in a single malloc > in the final binary. > > ubsan doesn't need this. You could link a .so file with ubsan, then link the > final binary with no knowledge that ubsan was ever involved, and it will work > just fine. (Or rather, it will after this patch.) In particular, I can't > currently build a python module with ubsan and then load it into a normal > python. The attached patch makes this work. > > The downside to this patch is that we can end up with multiple copies of the > ubsan runtime linked in. In reality this works fine because the ubsan runtime > doesn't keep much state (and it'd be difficult to make it do so correctly > because it has to support calling through files that are a mix of built and > not build with ubsan). We'll end up with multiple copies of ubsan's vptr > cache, which in turn will probably improve performance by improving locality. > > Please review! > > Nick While we're talking about linking sanitizer runtime, I have a question. You say other sanitizers need a to be linked at a single place. But is it true for asan on darwin ? Unlike on other platforms, asan on darwin uses a dynamic library, and so shouldn't it be possible to link it when building a dynamic library, and use it with a binary that don't have asan specific instrumentation ? As the runtime is a dynamic library, we shouldn't have the "multiple copies" issue. -- Jean-Daniel _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
