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);
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.
Q. But even if we find out which function to call, how will the analyzer know
which snode does that function belong ?
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 ?
STATUS AT THE END OF THE DAY :-
- try to create an intra-procedural link between the calls the calling and
returning snodes ( Done )
- figure out the program point where exploded graph would know about the
function calls ( Done )
- figure out how the exploded node will know which function to call ( Pending )
- create enodes and eedges for the calls ( Pending )
Thank you
- Ankur
> On 25-Jun-2021, at 2:23 AM, David Malcolm <dmalc...@redhat.com> wrote:
>
> On Thu, 2021-06-24 at 19:59 +0530, Ankur Saini wrote:
>> CURRENT STATUS :
>>
>> analyzer is now splitting nodes even at call sites which doesn’t have
>> a cgraph_edge. But as now the call and return nodes are not
>> connected, the part of the function after such calls becomes
>> unreachable making them impossible to properly analyse.
>>
>> AIM for today :
>>
>> - try to create an intra-procedural link between the calls the
>> calling and returning snodes
>> - find the place where the exploded nodes and edges are being formed
>> - figure out the program point where exploded graph would know about
>> the function calls
>>
>> —
>>
>> PROGRESS :
>>
>> - I initially tried to connect the calling and returning snodes with
>> an intraprocedural sedge but looks like for that only nodes which
>> have a cgraph_edge or a CFG edge are connected in the supergraph. I
>> tried a few ways to connect them but at the end thought I would be
>> better off leaving them like this and connecting them during the
>> creation of exploded graph itself.
>>
>> - As the exploded graph is created during building and processing of
>> the worklist, "build_initial_worklist ()” and “process_worklist()”
>> should be the interesting areas to analyse, especially the processing
>> part.
>>
>> - “build_initial_worklist()” is just creating enodes for functions
>> that can be called explicitly ( possible entry points ) so I guess
>> the better place to investigate is “process_worklist ()” function.
>
> Yes.
>
> Have a look at exploded_graph::process_node (which is called by
> process_worklist).
> The eedges for calls with supergraph edges happens there in
> the "case PK_AFTER_SUPERNODE:", which looks at the outgoing superedges
> from that supernode and calls node->on_edge on them, creating a
> exploded nodes/exploded edge for each outgoing-superedge.
>
> So you'll need to make some changes there, I think.
>
>>
>> —
>>
>> STATUS AT THE END OF THE DAY :-
>>
>> - try to create an intra-procedural link between the calls the
>> calling and returning snodes ( Abandoned )
>
> You may find the above useful if you're going to do it based on the
> code I mentioned above.
>
>> - find the place where the exploded nodes and edges are being formed
>> ( Done )
>> - figure out the program point where exploded graph knows about the
>> function call ( Pending )
>>
>
> Thanks for the update.
> Hope the above is helpful.
>
> Dave
