daily report on extending static analyzer project [GSoC]

[Ankur Saini]

AIM FOR TODAY: 

- Send the callstring patch to the patches list after sucessfull bootstrap and 
regress test
- Create some basic examples to see how virtual function are being called 
- Layout a basic `vtable_region : public region` subclass to store vtables 
found till now

---
PROGRESS :

- I sent the final callstring patch after sucessfully bootstraping and running 
the regress tests on it with no unexpected fails/passes. This time I wrote the 
mail manually(instead of using git send-mail) and attached the patch file with 
it.

- while testing this on various examples I created, I found out the following : 

1. vtable (which I guess looks something like _ZTV1<classname> in GIMPLE 
representation ) is either inside the contructor of the function or ( if 
default constructor is not overloaded ) in the function where the instance of 
the class is created.

2. when called ( call looks something like this OBJ_TYPE_REF(_3;(struct <
classname>)a_7->0) (a_7); ) we get the name of the class which functions is 
being called and the index in vtable where address is taken.

- Although at first I though it was imposible to get the info about the 
functions the vtable is holding by just looking at it's GIMPLE ir, after a 
little digging in ipa-devirt.c I found out that aprantly compiler's front end 
actually attaches this information ( known as BINFO ) with every tree (
RECORD_TYPE) which can be used to acess info about the same. ( I will be diggin 
more about it to see the extect to which I can use this BINFO to the project's 
advantage )

- So maybe the new region should hold a collection ( maybe vector ?) of cgraph 
nodes of the functions present in the vtable, which will be evaluated when the 
analyzer tries to find the function decl of the dynamically dicovered call.

- The problem arrises when we have a base class pointer and we don't exactly 
know which subclasse's method is being called. 

In a previous discussion (https://gcc.gnu.org/pipermail/gcc/2021-April/235335.html <https://gcc.gnu.org/pipermail/gcc/2021-April/235335.html>),
a possible plan to tackle this was to "potentially have the analyzer speculate 
about the subclasses it knows about, adding exploded edges to speculated calls 
for the various subclasses." But I would like look a bit more into ipa-devirt, 
especially possible_polymorphic_call_targets() function ( which seems to do 
most of the work similar to what we want to do ) to find something to overcome 
this problem.

---
STATUS AT THE END OF THE DAY :- 

- Send the callstring patch to the patches list after sucessfull bootstrap and 
regress test ( done )
- Create some basic examples to see how virtual function are being called ( done )
- Layout a basic `vtable_region : public region` subclass to store vtables 
found till now ( started )

Thank you
- Ankur