From: Ankur Saini <arsenic.secondary@gmail.com>
To: David Malcolm <dmalcolm@redhat.com>
Cc: gcc@gcc.gnu.org
Subject: Re: daily report on extending static analyzer project [GSoC]
Date: Sat, 24 Jul 2021 22:05:51 +0530 [thread overview]
Message-ID: <DB9F8932-BA00-46EA-9BC9-056D5317D7F0@gmail.com> (raw)
In-Reply-To: <720C2212-E325-487C-A8F8-EA33CB5C8FC1@gmail.com>
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
next prev parent reply other threads:[~2021-07-24 16:35 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-24 14:29 Ankur Saini
2021-06-24 20:53 ` David Malcolm
2021-06-25 15:03 ` Ankur Saini
2021-06-25 15:34 ` David Malcolm
2021-06-26 15:20 ` Ankur Saini
2021-06-27 18:48 ` David Malcolm
2021-06-28 14:53 ` Ankur Saini
2021-06-28 23:39 ` David Malcolm
2021-06-29 16:34 ` Ankur Saini
2021-06-29 19:53 ` David Malcolm
[not found] ` <AD7A4C2F-1451-4317-BE53-99DE9E9853AE@gmail.com>
2021-06-30 17:17 ` David Malcolm
2021-07-02 14:18 ` Ankur Saini
2021-07-03 14:37 ` Ankur Saini
2021-07-05 16:15 ` Ankur Saini
2021-07-06 23:11 ` David Malcolm
2021-07-06 22:46 ` David Malcolm
2021-07-06 22:50 ` David Malcolm
2021-07-07 13:52 ` Ankur Saini
2021-07-07 14:37 ` David Malcolm
2021-07-10 15:57 ` Ankur Saini
2021-07-11 17:01 ` Ankur Saini
2021-07-11 18:01 ` David Malcolm
2021-07-11 17:49 ` David Malcolm
2021-07-12 16:37 ` Ankur Saini
2021-07-14 17:11 ` Ankur Saini
2021-07-14 23:23 ` David Malcolm
2021-07-16 15:34 ` Ankur Saini
2021-07-16 21:27 ` David Malcolm
2021-07-21 16:14 ` Ankur Saini
2021-07-22 17:10 ` Ankur Saini
2021-07-22 23:21 ` David Malcolm
2021-07-24 16:35 ` Ankur Saini [this message]
2021-07-27 15:05 ` Ankur Saini
2021-07-28 15:49 ` Ankur Saini
2021-07-29 12:50 ` Ankur Saini
2021-07-30 0:05 ` David Malcolm
[not found] ` <ACE21DBF-8163-4F28-B755-6B05FDA27A0E@gmail.com>
2021-07-30 14:48 ` David Malcolm
2021-08-03 16:12 ` Ankur Saini
2021-08-04 16:02 ` Ankur Saini
2021-08-04 23:26 ` David Malcolm
2021-08-05 14:57 ` Ankur Saini
2021-08-05 23:09 ` David Malcolm
2021-08-06 15:41 ` Ankur Saini
2021-07-22 23:07 ` David Malcolm
2021-07-14 23:07 ` David Malcolm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DB9F8932-BA00-46EA-9BC9-056D5317D7F0@gmail.com \
--to=arsenic.secondary@gmail.com \
--cc=dmalcolm@redhat.com \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).