<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On 14 September 2017 at 16:19, Artem Dergachev <span dir="ltr"><<a href="mailto:noqnoqneo@gmail.com" target="_blank">noqnoqneo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
These are analyzer projects, which improve symbolic execution-based bug-finding of the clang's --analyze option, but not compilation or code generation. At the same time, these projects require relatively little understanding of the analyzer's internals (compared to other projects).<br>
<br>
* The body farm project does not require much knowledge about the analyzer, and mostly requires knowledge of the AST. The idea of the project is to synthesize ASTs of functions in order to help the analyzer what they do, when they are not available in the current translation unit (which is a problem because clang only compiles, and therefore analyzes, one translation unit at a time). Having an AST for an external function automagically allows the analyzer to "inline" it during analysis; lack of the AST would mean that the analyzer would assume that anything can happen when such function is called, which reduces precision of the analysis.<br>
<br>
Body-farmed ASTs are useful for system library functions that are simple enough. The AST does not need to necessarily do exactly what the function does, because the analyzer does not model everything exactly. For example, any atomic operations on integers may be replaced with regular integer operations because the analyzer would naturally do all its symbolic calculations atomically. You can see what functions are already there (very few, i guess we only have a couple of libdispatch functions that are modeled to immediately call their callback; George has recently farmed a body for std::call_once similarly in <a href="https://reviews.llvm.org/D37840" rel="noreferrer" target="_blank">https://reviews.llvm.org/D3784<wbr>0</a>, which turned out to be harder than usual) and follow the example to add the functions you're interested in. Various compiler builtins (eg., again, atomics?) might make a nice addition, and as far as I remember, Devin may have a couple of ideas as well.<br>
<br>
There is another mechanism in the analyzer, "evalCall", that allows analyzer checkers to compute the effects of the function directly, without consulting any sort of AST. The evalCall mechanism is older and in many (but not all) cases more powerful, but probably overly powerful and poorly scales with the number of checkers, so body farms are preferred whenever possible.<br>
<br>
Finally, there is an effort to allow the analyzer to import stuff from other translation units through ASTImporter (<a href="https://reviews.llvm.org/D30691" rel="noreferrer" target="_blank">https://reviews.llvm.org/D306<wbr>91</a>); if successful, as a neat side effect this may allow us to replace manual AST construction in body farms with simply feeding raw source code to the analyzer, which might be easier.<br></blockquote><div><br></div><div>Note that, it is possible to feed raw source code to the analyzer to be used through body farm (there are some limitations though). This functionality works without relying on the ASTImporter.<br></div><div>To see how this works there is a test case here: <a href="https://github.com/llvm-mirror/clang/blob/master/test/Analysis/model-file.cpp">https://github.com/llvm-mirror/clang/blob/master/test/Analysis/model-file.cpp</a></div><div>One of the modelled functions can be found here: <a href="https://github.com/llvm-mirror/clang/blob/master/test/Analysis/Inputs/Models/notzero.model">https://github.com/llvm-mirror/clang/blob/master/test/Analysis/Inputs/Models/notzero.model</a></div><div><br></div><div>Regards,</div><div>Gábor<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* The C++ operator-new project is about constructing the clang's CFG more accurately. Because most of the compilation relies on the LLVM's CFG, clang CFG is essentially used only by the analyzer and a couple of analysis-based compiler warnings, but not for compilation, and as such it is not entirely finished. I didn't look deeply into this problem yet, but it seems that by the time the analyzer sees the object construction element in the CFG, he wasn't informed that he needs to allocate symbolic memory to hold the newly constructed object, which needs fixing.<br>
<br>
While fixing the CFG is the first step, the ultimate goal of this project is to enable the "-analyzer-config c++-allocator-inlining=true" option by default. Which means that work would also need to be done on the analyzer side in order to understand the new CFG items and act accordingly.<br>
<br>
As an example of a recent CFG work i could recommend <a href="https://reviews.llvm.org/D15031" rel="noreferrer" target="_blank">https://reviews.llvm.org/D1503<wbr>1</a> which is not related to operator new, but gives an impression of how this area of our code looks.<br>
<br>
* As for contacts, this mailing list is the right place to discuss what you want to do, and our phabricator (<a href="http://reviews.llvm.org" rel="noreferrer" target="_blank">reviews.llvm.org</a>) is the right place to publish your patches. I've also CC'd the analyzer's code owner Anna and other potentially interested people.<div><div class="gmail-h5"><br>
<br>
On 9/14/17 2:27 AM, Jiten Thakkar via cfe-dev wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5">
Hi All,<br>
I was going through open projects page (<a href="https://clang-analyzer.llvm.org/open_projects.html" rel="noreferrer" target="_blank">https://clang-analyzer.llvm.o<wbr>rg/open_projects.html</a>) and wondering if that page is up to date or not. I found 'Explicitly model standard library functions with BodyFarm' and 'Enhance CFG to model C++ new more precisely' interesting to work on. I have some experience with LLVM API and modeling functions for verification as part of my masters project. So if anyone can let me know whom should I contact for those projects or how should I get started then it would be very helpful.<br>
<br>
Thanks,<br>
Jiten<br>
<br>
<br></div></div>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</blockquote>
<br>
</blockquote></div><br></div></div>