patch: link ubsan into shared libraries

[Jean-Daniel Dupas]

Le 13 août 2013 à 01:25, Nick Lewycky <nlewycky at google.com> 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