[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