[PATCH] D26454: Implement no_sanitize_address for global vars

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Dec 19 08:31:49 PST 2016


aaron.ballman added a comment.

In https://reviews.llvm.org/D26454#609578, @dougk wrote:

> Suppression of sanitizing is necessary if the variable is magically a memory-mapped device I/O address.
>  The linker can arrange for this to be the case using fancy scripts, or even just as simple as a section attribute that requires that you take up exactly a certain number of bytes in the section.
>  There was some thought that any non-default section should preclude sanitization, but Kostya said that, no, it would make sense to require explicit no-sanitize.  I (mistakenly) took that to mean "just do it", for which I apologize.


Thank you for the explanation, but I'm still wondering if this applies to only `address` sanitization, or to others as well, such as `memory` or `thread`. The fact that the declarative information in Attr.td is incorrect now is a concern. We can either address that concern by making the conflict go away for all sanitizer strings (which may not be sensible), or by making some complex changes to the way subject lists work (which may be more work than it's worth). The point to having a single `no_sanitize` attribute was so that we didn't need to add a new attribute every time we came up with a new sanitizer, but it was understood that this works because all of the sanitizers apply to the same constructs. This change breaks that assumption so that now one of the sanitizer strings diverges from all the rest, and I would like to avoid that.


https://reviews.llvm.org/D26454





More information about the cfe-commits mailing list