patch: link ubsan into shared libraries

[Kostya Serebryany]

+glider for the Darwin question.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130813/e5a1fafe/attachment.html>