[PATCH] D38971: Enhance libsanitizer support for invalid-pointer-pair.
Kostya Serebryany via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Oct 17 17:17:11 PDT 2017
kcc added a reviewer: llvm-commits.
kcc added a comment.
[disclaimer: this is the week of the LLVM developer conference, please expect delayed replies]
In https://reviews.llvm.org/D38971#899422, @jakubjelinek wrote:
> Besides the patch, we'd like to coordinate on options enabling this in the compilers.
> From what I can see, in clang it is currently an experimental asan-detect-invalid-pointer-pair param,
> what Martin has implemented is handle it as another kind of sanitization (separate kinds for pointer compare and pointer subtract),
> -fsanitize=pointer-subtract or -fsanitize=pointer-compare. One can then do:
> -fsanitize=address,pointer-subtract,pointer-compare etc., if address is not specified but one of these is, then
> right now we error out.
Yes, something like this sounds good.
I've prototyped this feature quite a while ago and tried it on a large code base and got a lot of false positives (or things that looked like false positives).
One problem is that C++'s std::less explicitly allows comparing two unrelated pointers and this is used in std::set and such.
I suspect that proper implementation in LLVM will need to have the instrumentation done in Clang, not in LLVM
See also https://bugs.llvm.org/show_bug.cgi?id=18989
Unfortunately, my team is unlikely to have time for this work in Q4 -- but we will gladly review patches.
> I could imagine pointer-subtract or pointer-compare to be supported even without address
> sanitization, where we'd link against libasan and add poisoning/unpoisoning/global variable registration etc., but not
> memory dereference checks, the problem is that the compiler then doesn't know if it should do the registration etc.
> in kernel-address or user address style.
We may do it in future but I wouldn't bother about pointer checks w/o asan for now -- not until we see how this feature works.
https://reviews.llvm.org/D38971
More information about the llvm-commits
mailing list