[cfe-dev] Checking if a ParmVarDecl is null in a Checker
Artem Dergachev via cfe-dev
cfe-dev at lists.llvm.org
Fri Apr 27 16:03:39 PDT 2018
Yep, indeed, this interface could be improved dramatically with a bit of
I'm usually getting away pretty well by searching the graph in clever
manners. If your dot viewer doesn't support text search across the graph
(most don't), you might want to convert it to .svg (eg. dot -Tsvg
graph.dot -o graph.svg) and open the svg in a web browser and then use
the find-on-page feature.
On 4/27/18 3:46 PM, Timothy J. Wood wrote:
>> On Apr 24, 2018, at 5:07 PM, Artem Dergachev <noqnoqneo at gmail.com> wrote:
>> I still strongly encourage you to have a look at the exploded graph. It'll immediately explain the whole analysis step-by-step to you and show you everything that's available on every step and you won't have to blindly experiment with random callbacks anymore. Please ask if you'll have problems understanding it.
> For extremely simple examples, the exploded graph is sort of tractable, but in large cases it is difficult to figure out what is going on. Maybe I missing something but I’d find it much more useful if I could find a way to:
> - Have my custom state (registered with REGISTER_MAP_WITH_PROGRAMSTATE) be logged in the nodes
This can be done by implementing the printState() callback. See
PthreadLockChecker, MallocChecker, RetainCountChecker, etc. For now not
many checkers implement it, but i wouldn't mind if all checkers
implemented it, as long as they don't print anything when they don't
> - Have error nodes marked red
You can use -trim-egraph and you'll only see error nodes and paths
towards them. Most error nodes would in this case be at the end of the
trimmed path (though if multiple non-fatal errors are produced on the
same path, the one in the middle would still not be very apparent).
Also checker error nodes, like all nodes created by the checker, are
marked with the checker's tag (at the bottom of the rectangle), so you
can search for the checker name in the graph to find them.
> - Have newly added/updated/removed state called out with some style changes (bold blue for added, bold black for updated, red for removed?)
Yep, that would have been great. I usually get away with searching for
the specific symbol or region or binding that i'm interested in - it
immediately highlights where a particular string has disappeared from
> - Add log messages of findings in my checker callbacks on the ProgramState or ExplodedNode
I didn't ever try that, but you could probably make nodes with custom
ProgramPointTag's that contain arbitrary strings.
> These might be a project to tackle on their own, but if there are tips for getting some useful meaning out of the exploded graph, it would be helpful.
More information about the cfe-dev