patch: link ubsan into shared libraries

[Alexander Potapenko]

ASan for Darwin is currently linked to executables, because it's
easier to deploy: the user just runs the binary, which sets up the
environment and re-execs itself.
It should be possible to avoid linking the runtime to executables, and
even run non-instrumented executables under ASan this way.
Feel free to comment on
https://code.google.com/p/address-sanitizer/issues/detail?id=201 if
you have additional questions or thoughts.

On Tue, Aug 13, 2013 at 11:49 AM, Jean-Daniel Dupas
<devlists at shadowlab.org> wrote:
>
> 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
>
>
>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits



-- 
Alexander Potapenko
Software Engineer
Google Moscow