[cfe-dev] Clang Static Analyzer Feature Bounties
Artem Dergachev via cfe-dev
cfe-dev at lists.llvm.org
Wed Mar 7 19:54:49 PST 2018
The Analyzer's documentation is a bit fragmented, but not entirely
lacking. The "Writing checker in 24 hours" video is a must-see
(https://youtu.be/kdxlsP5QVPw).
Apart from what you've already found and what's inevitably present in
the global llvm doxygen (i recommend googling clang class names, at
least at first), there's also in-tree text documents explaining overall
design of some parts:
https://github.com/llvm-mirror/clang/tree/master/docs/analyzer - if
you're interested in buffer overflows you should definitely read the one
about RegionStore.
There's also my out-of-tree workbook at
https://github.com/haoNoQ/clang-analyzer-guide/releases/download/v0.1/clang-analyzer-guide-v0.1.pdf
which reflects the current state of things (moderately up-to-date, some
things have changed slightly), but my opinions on what was a good idea
and what should work differently have changed since then.
There were two attempts to implement buffer overflow checks (namely
ArrayBoundChecker and ArrayBoundCheckerV2), but none of them ever became
feature-complete enough to be enabled by default yet. Not only there are
false positives, but warning messages are very hard to understand - they
often require intermediate notes along the execution path that led to
the bug (which are normally implemented via checker-specific
BugReporterVisitor objects) and in this case they're relatively tricky
to implement. I strongly suspect that any sensible work on buffer
overflows should start with proposing a good bug report visitor for one
of these checkers and then understanding its reports and seeing what
parts are broken based on that. Generally, buffer overflows are hard to
find statically; even though we seem overally suitable for that purpose
and have some useful facilities, details may get very tricky.
On 06/03/2018 8:29 AM, Benjamin Bales wrote:
> Hey guys,
>
> Thanks for your insightful responses! We've decided for now to first
> learn more about how development is done on the analyzer. We are
> primarily interested in contributing to the development of new
> checkers, particularly buffer issues (e.g. buffer overflow). Aside
> from looking at http://clang-analyzer.llvm.org/potential_checkers.html
> and http://clang-analyzer.llvm.org/checker_dev_manual.html, is there
> anything else we need to be aware of before we begin development?
> Also, what is the procedure for getting new checkers approved to add
> to the list of potential checkers?
>
> -Ben
>
> On Fri, Mar 2, 2018 at 6:41 PM, Artem Dergachev <noqnoqneo at gmail.com
> <mailto:noqnoqneo at gmail.com>> wrote:
>
> Yeah, I guess, The LLVM Foundation might be the right contact for
> the business/commercial side of things (not sure).
>
> On the technical side - I'm currently reviewing a large portion of
> patches for the analyzer. I'd be happy to review and accept any
> patches, regardless of where they came from - under the usual
> terms of the LLVM developer policy (you should totally have a look
> at it). Most importantly, please discuss any non-trivial work
> before you start coding, and split it up into small incremental
> patches that gradually improve an experimental feature until it's
> ready to be turned on by default - this is called "developing
> under the flag". For example, a new checker will stay in the alpha
> package during development, and an experimental analyzer core
> feature will be disabled by an -analyzer-config option. The main
> point here is to speed up reviews and make sure you don't need to
> re-do anything - because it's extremely hard to do anything right
> with LLVM in isolation. Of course, I cannot guarantee that any
> particular patch is going to be accepted, at least not before I
> see it.
>
>
> On 02/03/2018 3:17 PM, Jonas Toth via cfe-dev wrote:
>
> Hi,
>
> no. I dont have any major position, i would just potentially
> benefit
> from the bounties :P
>
> I dont know who has the power to decide about financial
> questions, but
> the LLVM deciders are most likely involved in it!
>
> All the best, Jonas :)
>
>
> Am 02.03.2018 um 23:21 schrieb Benjamin Bales:
>
> Hi Jonas!
>
> Nice to hear from you. We could certainly add clang-tidy
> to our
> roadmap. The primary reason we are interested in
> improving the clang
> static analyzer is because we build our commercial
> product, CodeAI
> (www.mycode.ai <http://www.mycode.ai>), on top of it. I
> am hiring an internal work force to
> enhance the checkers, but I am interesting in exploring
> open source
> alternatives to push forward this work. I have some
> ideas, but I
> think it would be best if we could arrange a phone call
> next week
> sometime to discuss things. Are you the maintainer of
> this project?
>
> -Ben
>
> On Fri, Mar 2, 2018 at 4:59 PM, Jonas Toth via cfe-dev
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>
> wrote:
>
> Hi,
>
> nice to hear! Would you consider clang-tidy as second
> part of clangs
> static analysis framework as worthwhile, too?
>
> All the best, Jonas
>
>
> Am 02.03.2018 um 22:48 schrieb Benjamin Bales via cfe-dev:
>
> Greetings Clang Front End Developers!
>
> My name is Benjamin Bales, and I am the CTO and
> co-founder of
> QbitLogic, a startup company in Atlanta. We are
> interested in
> sponsoring feature bounties to further develop the
> clang static
> analyzer. Can someone recommend me a point of
> contact with whom I can
> open a dialogue? Let me know. Thanks!
>
> Sincerely,
>
> _______________________________________________
> 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>
>
>
>
> _______________________________________________
> 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>
>
>
>
>
>
> --
> Benjamin Bales
> Chief Technology Officer
> QbitLogic
> 1180 West Peachtree Street, Ste. 2425
> Atlanta, GA 30309
> 470-214-0598
>
> CONFIDENTIALITY NOTICE
>
> This e-mail and any files transmitted with it are confidential and are
> intended solely for the use of the individual or entity to which they
> are addressed. This communication may contain privileged attorney
> material or other Property and Confidential matter. If you are not
> the intended recipient or the person responsible for delivering the
> e-mail for the intended person, be advised that you have received this
> e-mail in error and that any use, dissemination, forwarding, printing,
> or copying of this e-mail is strictly prohibited. If you believe you
> have received this e-mail in error, please immediately delete this
> e-mail and notify Benjamin Bales by telephoning 470-214-0598
> <tel:470-214-0598>.
>
More information about the cfe-dev
mailing list