[PATCH] The msan interface stubs for non-instrumented code were missing a bunch of entry points.

Chandler Carruth chandlerc at gmail.com
Thu Feb 20 02:10:09 PST 2014


On Thu, Feb 20, 2014 at 12:42 AM, Evgeniy Stepanov <eugenis at google.com>wrote:

>   We should really just get rid of this case. It does not do anything
> useful: you still need to protect these calls with #ifdef-s to support
> other compilers.
>
>   Other sanitizers don't provide interface stubs for non-instrumented code.
>
>   Even so, consistency is good. Feel free to submit this change if it
> helps your use case.
>

Currently we have code which is not fully guarded by
__has_feature(memory_sanitizer) and using these APIs. It used to work
because it used the stubs instead. Now it references APIs which have no
stubs.

While I'm adding stubs, I'm just as happy to move all code behind
__has_feature(memory_sanitizer). I don't have a strong opinion about stubs
vs. no-stubs. As you've pointed out, the *behavior* won't be sensible with
the stubs, so it is mostly a matter of whether having stubs is a useful
simplification for programs that need to interface with msan when it is
enabled but no-op such interfacing when it is not enabled. You would have a
better idea than I about what the correct path forward is here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140220/8692d146/attachment.html>


More information about the llvm-commits mailing list