daily report on extending static analyzer project [GSoC]

Ankur Saini arsenic.secondary@gmail.com
Sat Jun 26 15:20:09 GMT 2021


> On 25-Jun-2021, at 9:04 PM, David Malcolm <dmalcolm@redhat.com> wrote:
> 
> On Fri, 2021-06-25 at 20:33 +0530, Ankur Saini wrote:
>> AIM for today : 
>> 
>> - try to create an intra-procedural link between the calls the calling
>> and returning snodes
>> - figure out the program point where exploded graph would know about
>> the function calls
>> - figure out how the exploded node will know which function to call
>> - create enodes and eedges for the calls
>> 
>>>> 
>> PROGRESS :
>> 
>> - I created an intraprocedural link between where the the splitting is happening to connect the call and returning snodes. like this :-
>> 
>> (in supergraph.cc at "supergraph::supergraph (logger *logger)" )
>> ```
>> 185             if (cgraph_edge *edge = supergraph_call_edge (fun, stmt))
>> 186             {
>> 187                m_cgraph_edge_to_caller_prev_node.put(edge, node_for_stmts);
>> 188                node_for_stmts = add_node (fun, bb, as_a <gcall *> (stmt), NULL);
>> 189                m_cgraph_edge_to_caller_next_node.put (edge, node_for_stmts);
>> 190             }
>> 191             else
>> 192             {
>> 193               gcall *call = dyn_cast<gcall *> (stmt);
>> 194               if (call)
>> 195               {
>> 196                 supernode *old_node_for_stmts = node_for_stmts;
>> 197                 node_for_stmts = add_node (fun, bb, as_a <gcall *> (stmt), NULL);
>                                                          ^^^^^^^^^^^^^^^^^^^^^
> Given the dyn_cast of stmt to gcall * at line 193 you can use "call"
> here, without the as_a cast, as you've already got "stmt" as a gcall *
> as tline 193.

ok

> 
> You might need to add a hash_map recording the mapping from such stmts
> to the edges, like line 189 does.  I'm not sure, but you may need it
> later.

but the node is being created if there is no cgraph_edge corresponding to the call, so to what edge will I map “node_for_stmts" to ?

> 
> 
>> 198
>> 199                 superedge *sedge = new callgraph_superedge (old_node_for_stmts,
>> 200                     node_for_stmts,
>> 201                     SUPEREDGE_INTRAPROCEDURAL_CALL,
>> 202                     NULL);
>> 203                 add_edge (sedge);
>> 204               }                
>> 205             }
>> ```
>> 
>> - now that we have a intraprocedural link between such calls, and the
>> analyzer will consider them as “impossible edge” ( whenever a "node-
>>> on_edge()” returns false ) while processing worklist, and I think this
>> should be the correct place to speculate about the function call by
>> creating exploded nodes and edges representing calls ( maybe by adding
>> a custom edge info ).
>> 
>> - after several of failed attempts to do as mentioned above, looks like
>> I was looking the wrong way all along. I think I just found out what my
>> mentor meant when telling me to look into "calls node->on_edge”. During
>> the edge inspection ( in program_point::on_edge() ) , if it’s an
>> Intraprocedural s sedge, maybe I can add an extra intraprocedural sedge
>> to the correct edge right here with the info state of that program
>> point. 
> 
> I don't think we need a superedge for such a call, just an
> exploded_edge.  (Though perhaps adding a superedge might make things
> easier?  I'm not sure, but I'd first try not bothering to add one)

ok, will scratch this idea for now.

> 
>> 
>> Q. But even if we find out which function to call, how will the
>> analyzer know which snode does that function belong ?
> 
> Use this method of supergraph:
>  supernode *get_node_for_function_entry (function *fun) const;
> to get the supernode for the entrypoint of a given function.
> 
> You can get the function * from a fndecl via DECL_STRUCT_FUNCTION.

so once we get fndecl, it should be comparatively smooth sailing from there. 

My attempt to get the value of function pointer from the state : -

- to access the region model of the state, I tried to access “m_region_model” of that state.
- now I want to access cluster for a function pointer.
- but when looking at the accessible functions to region model class, I couldn’t seem to find the fitting one. ( the closest I could find was “region_model::get_reachable_svalues()” to get a set of all the svalues reachable from that model )

> 
>> Q. on line 461 of program-point.cc 
>> 
>> ```
>> 457             else
>> 458               {
>> 459                 /* Otherwise, we ignore these edges  */
>> 460                 if (logger)
>> 461                   logger->log ("rejecting interprocedural edge");
>> 462                 return false;
>> 463               }
>> ```
>> why are we rejecting “interprocedural" edge when we are examining an
>> “intraprocedural” edge ? or is it for the "cg_sedge->m_cedge” edge,
>> which is an interprocedural edge ?
> 
> Currently, those interprocedural edges don't do much.  Above the "else"
> clause of the lines above the ones you quote is some support for call
> summaries.
> 
> The idea is that we ought to be able to compute summaries of what a
> function call does, and avoid exponential explosions during the
> analysis by reusing summaries at a callsite.  But that code doesn't
> work well at the moment; see:
>  https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=99390 <https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=99390>
> 
> If you ignore call summaries for now, I think you need to change this
> logic so it detects if we have a function pointer that we "know" the
> value of from the region_model, and have it generate an exploded_node
> and exploded_edge for the call.  Have a look at how SUPEREDGE_CALL is
> handled by program_state and program_point; you should implement
> something similar, I think.  Given that you need both the super_edge,
> point *and* state all together to detect this case, I think the logic
> you need to add probably needs to be in exploded_node::on_edge as a
> specialcase before the call there to next_point->on_edge.
> 
> Hope this is helpful
> Dave

Thank you
- Ankur



More information about the Gcc mailing list