[cfe-dev] Learning how to use and deploy 'scan-build'
Anna Zaks via cfe-dev
cfe-dev at lists.llvm.org
Sat Nov 12 10:18:34 PST 2016
> On Nov 12, 2016, at 5:13 AM, Martin J. O'Riordan <Martin.ORiordan at movidius.com> wrote:
>
> Thanks very much for your very helpful feedback, and I now have it mostly working. However, I must still be doing something wrong as I am not seeing any analysis reports, and it would be great if someone could point out what I am doing wrong.
>
> I am using ‘clang’ v3.9.0 built with Visual Studio 2013 on Windows, but running the test under Cygwin. In the description below I use the terms ‘<tools-cygpath>’, ‘<tools-WINPATH>’, ‘<test-cygpath>’ and ‘<test-WINPATH>’ to indicate the paths to the tools and test source from both Cygwin’s and Windows’ perspectives. The actual paths are too long to trouble you with, and not useful. My version of Perl on Cygwin is v5.14.4.
>
> The following describes how I am invoking ‘scan-build’ and my observations of its execution - sorry for the long description, but I did not want to elide anything that may be useful:
>
> // How I invoke 'scan-build'::
> <tools-cygpath>/bin/scan-build \
> --use-cc clang \
> --use-c++ clang++ \
> -enable-checker “core,security" \
I recommend not limiting the analysis to these 2 packages unless you see that the other packages turned on by default report false positives on your codebase.
> -v -v -v \
> -o check \
> --html-title "Testing ScanBuild" \
> make build
>
> // 'scan-build' invokes 'c++-analyzer' as follows (these are the parameters I pass to the compiler normally)::
> <tools-cygpath>/bin/../libexec/c++-analyzer \
> -v -c -Wall -fverbose-asm -UNDEBUG \
> -O3 -std=c++14 testingScanBuild.cpp -o testingScanBuild.o
>
> // 'c++-analyzer' invokes my 'clang++' as follows (these are the normal options we expect)::
> "<tools-WINPATH>\\bin\\clang++.exe" -cc1 -triple shave -S \
> -disable-free -disable-llvm-verifier -discard-value-names \
> -main-file-name testingScanBuild.cpp \
> -mrelocation-model static -mthread-model posix \
> -mdisable-fp-elim -masm-verbose -no-integrated-as -funroll-loops \
> -mllvm -unroll-allow-partial \
> -mno-zero-initialized-in-bss -fno-rtti \
> -mllvm -enable-misched \
> -mllvm -enable-aa-sched-mi \
> -mllvm -misched-bottomup \
> -mllvm -misched=ilpmax \
> -v -dwarf-column-info -debugger-tuning=gdb \
> -coverage-file "<test-WINPATH>\\ScanBuild\\testingScanBuild.o" \
> -resource-dir "<tools-WINPATH>\\bin\\..\\lib\\clang\\3.9.0" \
> -U NDEBUG \
> -internal-externc-isystem "<tools-WINPATH>\\include\\c++" \
> -internal-externc-isystem "<tools-WINPATH>\\include" \
> -O3 -Wall -std=c++14 \
> -fdeprecated-macro -fno-dwarf-directory-asm \
> -fdebug-compilation-dir "<test-WINPATH>\\ScanBuild" \
> -ferror-limit 19 -fmessage-length 0 -ffreestanding \
> -fallow-half-arguments-and-returns -fobjc-runtime=gcc \
> -fdiagnostics-show-option -vectorize-loops -vectorize-slp \
> -o "D:\\tmp\\testingScanBuild-413704.s" \
> -x c++ testingScanBuild.cpp
>
> // Then 'c++-analyzer' reports this following which mirrors the usual
> // invocation, but also includes many Analysis options (indented)::
> [LOCATION]: <test-cygpath>/ScanBuild
> #SHELL (cd '<test-cygpath>/ScanBuild' && '<tools-cygpath>/bin/clang' \
> '-cc1' '-triple' 'shave' '-analyze' '-disable-free' \
> '-disable-llvm-verifier' '-discard-value-names' \
> '-main-file-name' 'testingScanBuild.cpp' \
> '-analyzer-store=region' \
> '-analyzer-opt-analyze-nested-blocks' \
> '-analyzer-eagerly-assume' \
> '-analyzer-checker=core' \
> '-analyzer-checker=unix' \
> '-analyzer-checker=deadcode' \
> '-analyzer-checker=cplusplus' \
> '-analyzer-checker=security.insecureAPI.UncheckedReturn' \
> '-analyzer-checker=security.insecureAPI.getpw' \
> '-analyzer-checker=security.insecureAPI.gets' \
> '-analyzer-checker=security.insecureAPI.mktemp' \
> '-analyzer-checker=security.insecureAPI.mkstemp' \
> '-analyzer-checker=security.insecureAPI.vfork' \
> '-analyzer-checker=nullability.NullPassedToNonnull' \
> '-analyzer-checker=nullability.NullReturnedFromNonnull' \
> '-analyzer-output' \
> 'plist' \
> '-w' '-mrelocation-model' 'static' '-mthread-model' 'posix' \
> '-mdisable-fp-elim' '-masm-verbose' '-no-integrated-as' '-funroll-loops' \
> '-mllvm' '-unroll-allow-partial' \
> '-mno-zero-initialized-in-bss' '-fno-rtti' \
> '-mllvm' '-enable-misched' \
> '-mllvm' '-enable-aa-sched-mi' \
> '-mllvm' '-misched-bottomup' \
> '-mllvm' '-misched=ilpmax' \
> '-v' '-dwarf-column-info' '-debugger-tuning=gdb' \
> '-resource-dir' '<tools-WINPATH>\bin\..\lib\clang\3.9.0' \
> '-U' 'NDEBUG' \
> '-internal-externc-isystem' '<tools-WINPATH>\include\c++' \
> '-internal-externc-isystem' '<tools-WINPATH>\include' \
> '-O3' '-std=c++14' \
> '-fdeprecated-macro' '-fno-dwarf-directory-asm' \
> '-fdebug-compilation-dir' '<test-WINPATH>\ScanBuild' \
> '-ferror-limit' '19' '-fmessage-length' '0' '-ffreestanding' \
> '-fallow-half-arguments-and-returns' '-fobjc-runtime=gcc' \
> '-fdiagnostics-show-option' '-vectorize-loops' '-vectorize-slp' \
> '-analyzer-display-progress' \
> '-analyzer-checker' 'core,security' \
> '-analyzer-opt-analyze-headers' \
> '-analyzer-output=html' \
> '-o' '<test-cygpath>/ScanBuild/check/2016-11-12-114955-13712-1' \
> '-x' 'c++' 'testingScanBuild.cpp')
>
> // The analyser reports the following progress, I have elided references to
> // headers and other non-relevant files::
> ANALYZE (Syntax): testingScanBuild.cpp verifyResult
> ANALYZE (Syntax): testingScanBuild.cpp verifyResult
> ANALYZE (Syntax): testingScanBuild.cpp main
> ANALYZE (Syntax): testingScanBuild.cpp generateInputData
> ANALYZE (Syntax): testingScanBuild.cpp generateOutputData
> ANALYZE (Path, Inline_Regular): testingScanBuild.cpp main
>
> // Finally it concludes with::
> scan-build: Removing directory '<test-cygpath>/ScanBuild/check/2016-11-12-115552-7812-1' because it contains no reports.
> scan-build: No bugs found.
>
> But in my test, I have deliberately seeded it with unreachable code that I would expect the dead-code checker to find:
>
> bool flag = someTestCondition == true;
>
> if (flag) {
> doSomethingInteresting();
> } else if (flag) { // Same test as above
> unreachableCode(); // Expecting an SA diagnostic here
The checkers you’ve enabled will not find this bug. Try testing with devision by zero or null pointer dereference:
int x = 0;
return 5/x;
or
int *x = 0;
*x = 5;
> } else {
> doNothing();
> }
>
> I’m sure that there is something really simple that I am missing, but I have no idea what it is.
>
> Thanks,
>
> MartinO
>
> From: Anna Zaks [mailto:ganna at apple.com]
> Sent: 11 November 2016 23:39
> To: Aleksei Sidorin <a.sidorin at samsung.com>
> Cc: Martin J. O'Riordan <martin.oriordan at movidius.com>; cfe-dev <cfe-dev at lists.llvm.org>
> Subject: Re: [cfe-dev] Learning how to use and deploy 'scan-build'
>
>
>> On Nov 11, 2016, at 6:26 AM, Aleksei Sidorin via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>>
>> Hello Martin!
>>
>> 11.11.2016 16:48, Martin J. O'Riordan via cfe-dev пишет:
>>> I am working on adding ‘scan-build’ to the set of tools we include with our release of ‘clang’, and trying to determine the minimal set of components needed to be able to successfully use ‘scan-build’. The documentation for this is fairly thin, so there are many things I am having to learn.
>>>
>>> Currently we just provide the compiler itself, along with the headers and libraries for our SHAVE target. I would like to add a lot of the additional tools and utilities that CLang/LLVM provide with future versions, ‘scan-build’ is one of these, and ‘clang-tidy’, etc., but not a complete set.
>>>
>>> In addition to the ‘scan-build’ Perl script itself, I also need the ‘ccc-analyzer’ and ‘c++-analyzer’ Perl scripts, and this appears to run without error; but I would like to know are their other components that I need to ensure that it is fully functional?
>> As I remember, Perl scan-build doesn't have any additional dependencies.
>>
>>>
>>> I would like to know what is the “core set” of analysers? I listed the full set of analysers in ‘clang’ v3.9.0 and some of these names are prefixed with ‘core.’ so I presume these are the ones that comprise the core set?
>> The "core" set is responsible for basic modelling of some functions in path-sensitive mode, they are not the analyzer core itself. Shortly, analyzer has two kinds of checkers - AST/CFG based (fast) and path-sensitive (slow but more powerful). If you need any path-sensitive checkers, you should also enable "core" checkers for more precise modelling.
>>
>> // TODO: enable "core" automatically in such cases?
>
> I would recommend to start with the default set of checkers and disable the ones you do not find useful for your codebase (if any).
>
>
>>> When enabling others I presume I have to add a comma-separated list to the ‘-enable-checker’ option, for example ‘debug.Stats,unix.Malloc’. The names in the list of checks are formed with separating dot characters, does selecting something like ‘security’ enable all the checkers in the ‘security.*’ group, or do I have to enable them one at a time?
>> To enable a full package, you should just point it. Example: "-enable-checker core,security"
>>
>>>
>>> Sorry if this is all answered in some part of the documentation I haven’t found, and please point me at it.
>> You can find some additional information on http://clang-analyzer.llvm.org <http://clang-analyzer.llvm.org/>
>>
>>>
>>> Thanks,
>>>
>>> MartinO
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>>
>>
>> --
>> Best regards,
>> Aleksei Sidorin
>> Software Engineer,
>> IMSWL-IMCG, SRR, Samsung Electronics
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20161112/c716bdd9/attachment.html>
More information about the cfe-dev
mailing list