I'd like to teach clang -cc1 to use VFS overlay when searching for blacklist file specified by -fsanitize-blacklist.
Details
- Reviewers
arphaman kubamracek delcypher JDevlieghere - Commits
- rG3dab5e825b8c: Reland 'Add VFS support for sanitizers' blacklist'
rL374006: Reland 'Add VFS support for sanitizers' blacklist'
rC374006: Reland 'Add VFS support for sanitizers' blacklist'
rG96ac97a42132: Add VFS support for sanitizers' blacklist
rL373977: Add VFS support for sanitizers' blacklist
rC373977: Add VFS support for sanitizers' blacklist
Diff Detail
- Repository
- rL LLVM
Event Timeline
Hi Jan, what's the is motivation for the sanitizer blacklists to support a VFS overlay in the driver?
We discussed offline and agreed that we don't need to use overlay in driver at all. I simplified the patch.
I completely forgot about error handling which would be tricky in current place where I devirtualize files. We discussed offline and seems like it will be better to use VFS in SanitizerBlacklist anyway.
I took a look at SanitizerSpecialCaseList and I'm now thinking it might not be necessary to plumb VFS there. It's derived from llvm::SpecialCaseList whose sole interaction with filesystem is that it has couple named constructors that read a file and init an instance with its content.
It feels like dealing with paths and files is actually out of scope for SpecialCaseList and the natural interface is probably just a buffer.
clang/test/CodeGen/Inputs/sanitizer-blacklist-vfsoverlay.yaml | ||
---|---|---|
7 ↗ | (On Diff #221397) | For template substitutions I prefer to have placeholders delimited by @ symbols e.g. @REAL_FILE@. This helps avoid situations where text like REAL_FILE might appear in the template where we don't want them substituted. Having a @ symbol at the end avoids issue where a placeholder is a prefix of another (e.g. REAL_FILE is a prefix of REAL_FILE_ABSOLUTE). It doesn't matter for this patch but I think it's a good convention to follow. |
clang/test/CodeGen/ubsan-blacklist.c | ||
10 ↗ | (On Diff #221397) | Are we allowed to use sed here? For Windows builds can we assume it's available? |
clang/test/CodeGen/ubsan-blacklist.c | ||
---|---|---|
10 ↗ | (On Diff #221397) | Good question! Apparently I should just use %T etc. and echo to %t-vfsoverlay.yaml. However, since we use sed in other clang-scan-deps tests too - would you be fine with me addressing this in all tests at once as a separate patch? |
clang/test/CodeGen/ubsan-blacklist.c | ||
---|---|---|
10 ↗ | (On Diff #221397) | Sure separate patch sounds good. |
LGTM
clang/lib/AST/ASTContext.cpp | ||
---|---|---|
833 ↗ | (On Diff #223655) | You could reserve the number of elements in Paths. |
Broke Windows:
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/11306
Looks related to this: https://bugs.llvm.org/show_bug.cgi?id=43272
The fix is probably to follow the pattern I started using in rC371663, use %/T and %/S instead of %T and %S.