daily report on extending static analyzer project [GSoC]

[David Malcolm]

On Tue, 2021-06-29 at 22:04 +0530, Ankur Saini wrote:
> AIM for today : 
> 
> - filter out the the nodes which already have an supergraph edge
> representing the call to avoid creating another edge for call
> - create enode for destination
> - create eedge representing the call itself
> 
> —
> 
> PROGRESS :
> 
> - in order to filter out only the relevant edges, I simply used the
> fact that the edge that we care about will not have any call_graph
> edge associated with it. ( means “sedge->get_any_callgraph_edge()"
> would return NULL )
> 
> - I was also successfully able to create the enode and connect it
> with an eedge representing the call and was able to see it calling
> the correct function on some examples. :)
> 
> - But the problem now is returning from the function, which turned
> out bigger then I though it was. 
> 
> - In order to tackle this problem, I first tried to update the
> call_string with the call, but the only way to push a call to the
> string I found was via “call_string::push_call()” function which
> finds the return_superedge from the cgraph_edge representing the
> return call ( which we don’t have )
> 
> so I decided to make an overload of "call_string::push_call()” which
> directly takes a return_superedge and push it the underlying vector
> of edges instead of taking it from the calling edge. It looks
> something like this :-
> 
> File:  {$SCR_DIR}/gcc/analyzer/call-string.cc
> <http://call-string.cc/>
> 158: void
> 159: call_string::push_call(const return_superedge *return_sedge)
> 160: {
> 161:   gcc_assert (return_sedge);
> 162:   m_return_edges.safe_push (return_sedge);
> 163: }

Looks reasonable.

> 
> I also created a temporary return_superedge ( as we now have the
> source and destination ), and try to update the call_string with it
> just to find out that call_string is private to program_point. 

I confess I'm having a little difficulty visualizing what the superedge
looks like with this new edge.


FWIW you can use the accessor:
  program_point::get_call_string ()
to get it in const form:
  const call_string &get_call_string () const { return m_call_string; }

but it sounds like you're trying to change things.



The purpose of class call_string is to track the stack of call sites,
so that when we return from a function, we return to the correct call
site.

I wonder if class call_string could be updated so that rather than
capturing a vec of superedges:
  auto_vec<const return_superedge *> m_return_edges;
it captures a vec of gcall *?

Then you wouldn't need a superedge ahead of time for the return from
the call.

I'm not sure if that would work, but that might be another approach you
could try, and might be simplest.  I'm not sure.

I *think* we only use the return_superedge within
program_point::on_edge, comparing against the successor edge, but that
code could be rewritten to look at which gcall * is associated with the
edge.

(again, I'm not sure, but maybe it's simpler)


> So my plan for next day would be to create a custom function to the
> program_point class the update the call stack and return back to
> correct spot. 
> 
> If there is a better way of doing it then do let me know.
> 
> STATUS AT THE END OF THE DAY :- 
> 
> - filter out the the nodes which already have an supergraph edge
> representing the call ( Done )
> - create enode for destination ( Done )
> - create eedge representing the call itself ( Done ? )
> 
> —
> 
> P.S. it has been over a week since I sent a mail to    
> overseers@gcc.gnu.org <mailto:overseers@gcc.gnu.org> regarding the
> ssh key incident and I haven’t got any response form them till now,
> does this usually take this long for them to respond ? or does this
> means I didn’t provide some information to them that I should have.
> Is there something else I can do regarding this problem ?

I'd try resending the email.

Hope this is helpful
Dave