[GSoC-2021] Interested in project `Extend the static analysis pass`
Hi all, I am an undergraduate student in AMU, Aligarh. I am interested in the project* `Extend the static analysis pass`. *I have followed this( https://gcc.gnu.org/pipermail/gcc/2021-March/234941.html) and been able to successfully build and successfully ran and pass the test suite for C and C++. I found this sub-project `C++ support (new/delete checking, exceptions, etc)` interesting and may be the conservative code for this can be made along the lines of malloc/free implementation in C. I found here( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355) that some part of it has already been implemented . I would like to expand it further and learn about it, maybe start with writing some test cases, please let me know. Further, I am inclined on this( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97111). Let me know if it is still available. Looking forward to hearing from you guys. Thanks, Saloni Garg
Re: [GSoC-2021] Interested in project `Extend the static analysis pass`
Hi, I have tried the following examples with the fanalyzer option in g++.
1 (a)
void myFunction()
{
char *p =new char;
}
int main()
{
func();
return 0;
}
1(b)
void myFunction()
{
try {
char *p = new char;
throw p;
}
catch(...) {
}
}
int main()
{
myFunction();
return 0;
}
In 1(a), there is no exception handling. When I ran `cc1plus`, a memory
leak was reported as shown in bug #94355.
In 1(b), there is a use of exception handling. When I ran cc1plus`, no
memory leaks were detected. I believe there should be one. Can you please
confirm from your side as well? As you said all the calls to try, catch and
throw got converted to _cxa prefixed functions. I am trying to find the
places where the corresponding checks can be placed for the analysis of
exception handling in gimple IR.
Please, let me know your thoughts on this.
On Fri, Mar 26, 2021 at 12:48 AM David Malcolm wrote:
> On Thu, 2021-03-25 at 14:52 +0530, Saloni Garg via Gcc wrote:
> > Hi all,
> > I am an undergraduate student in AMU, Aligarh. I am interested in the
> > project* `Extend the static analysis pass`. *I have followed this(
> > https://gcc.gnu.org/pipermail/gcc/2021-March/234941.html) and been
> > able to
> > successfully build and successfully ran and pass the test suite for C
> > and
> > C++.
> >
> > I found this sub-project `C++ support (new/delete checking,
> > exceptions,
> > etc)` interesting and may be the conservative code for this can be
> > made
> > along the lines of malloc/free implementation in C. I found here(
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355) that some part of
> > it
> > has already been implemented . I would like to expand it further and
> > learn
> > about it, maybe start with writing some test cases, please let me
> > know.
> >
> > Further, I am inclined on this(
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97111). Let me know if
> > it is
> > still available.
> >
> > Looking forward to hearing from you guys.
> > Thanks,
> > Saloni Garg
>
> Hi!
>
> I'm the author/maintainer of the static analysis pass, and would be the
> mentor for any GSoC project(s) involving it.
>
> I've already implemented most of the new/delete checking in GCC 11; the
> big missing component there is exception-handling.
>
> Implementing exception-handling in the analyzer could make a good GSoC
> project: it's non-trivial, but hopefully doable in one summer. I see
> you've already seen bug 97111, and there are some links in that bug to
> resources. Given that the analyzer runs on the gimple-ssa
> representation, by the time it sees the code, much of the exception-
> handling has already been translated into calls to various __cxa_-
> prefixed functions in the C++ runtime, so part of the work would
> involve "teaching" the analyzer about those functions. One way to make
> a start on this would be to create a collection of trivial C++ examples
> that use exceptions, and then look at analyzer dumps to see what IR is
> being "seen" by the analyzer for the various constructs. (I actually
> started this a long time ago and have a very crude barely-working
> prototype, but it was just the start, and I've forgotten almost all of
> it...)
>
> Hope this is helpful
> Dave
>
>
>
Re: [GSoC-2021] Interested in project `Extend the static analysis pass`
On Sun, Mar 28, 2021 at 8:03 PM David Malcolm wrote:
> On Sun, 2021-03-28 at 18:06 +0530, Saloni Garg wrote:
> > Hi, I have tried the following examples with the fanalyzer option in
> > g++.
> >
> > 1 (a)
> > void myFunction()
> > {
> > char *p =new char;
> > }
> > int main()
> > {
> >func();
> >return 0;
> > }
>
> BTW, are you familiar with Compiler Explorer (godbolt.org)? It's very
> handy for testing small snippets of code on different compilers and
> different compiler versions. Though I don't know how long the URLs are
> good for (in terms of how long code is cached for)
>
> Fixing up the name of the called function to "func":
> https://godbolt.org/z/TnM6n4xGc
> I get the leak report, as per RFE 94355. This warning looks correct,
> in that p does indeed leak.
>
> Hi, thanks for the effort, sorry for the typo. I now know about the
godbolt.org and it is certainly useful.
> I should mention that the analyzer has some special-casing for "main",
> in that the user might not care about one-time leaks that occur within
> "main", or something only called directly by it; this doesn't seem to
> be the case here. If I remove the implementation to main, the analyzer
> still correctly complains about the leak:
> https://godbolt.org/z/zhK4vW6G8
>
> That's something new. I also didn't know that. I believe we can shift our
minimal example to just func() and remove main().
> : In function 'void func()':
> :4:1: warning: leak of 'p' [CWE-401] [-Wanalyzer-malloc-leak]
> 4 | }
> | ^
> 'void func()': events 1-2
> |
> |3 | char *p =new char;
> | | ^~~~
> | | |
> | | (1) allocated here
> |4 | }
> | | ~
> | | |
> | | (2) 'p' leaks here; was allocated at (1)
> |
>
>
> > 1(b)
> > void myFunction()
> > {
> > try {
> > char *p = new char;
> > throw p;
> > }
> > catch(...) {
> > }
> > }
> > int main()
> > {
> >myFunction();
> >return 0;
> > }
> > In 1(a), there is no exception handling. When I ran `cc1plus`, a
> > memory
> > leak was reported as shown in bug #94355.
> > In 1(b), there is a use of exception handling. When I ran cc1plus`,
> > no
> > memory leaks were detected. I believe there should be one. Can you
> > please
> > confirm from your side as well?
>
> I too am seeing no diagnostics on 1(b).
>
Thanks for confirming.
>
> > As you said all the calls to try, catch and
> > throw got converted to _cxa prefixed functions.
>
> -fdump-ipa-analyzer=stderr shows the _cxa-prefixed functions:
> https://godbolt.org/z/YMa9dE6aM
>
> > I am trying to find the
> > places where the corresponding checks can be placed for the analysis
> > of
> > exception handling in gimple IR.
>
> Have a look at exploded_node::on_stmt in engine.cc; in particular, see
> the GIMPLE_CALL case in the switch statement. Most of the the
> analyzer's "knowledge" of the behaviors of specific functions is here,
> or called from here.
>
> The simpler cases are handled in the call to
> m_region_model->on_call_pre
> for functions which merely update state, which are implemented in
> region-model-impl-calls.cc
>
> Cases involving state machines (e.g. allocation) are handled in the:
> sm.on_stmt
> call torwards the bottom of the function.
>
> But exception-handling is a special case, in that it affects control
> flow. The closest thing to compare it to currently within the analyzer
> is setjmp/longjmp, so it's worth stepping through how that is handled.
> In particular, the real implementation of longjmp involves directly
> updating the program counter, registers and stack, potentially popping
> multiple stack frames. This is similar to what throwing an exception
> does.
>
> So I'd recommend looking at the analyzer's implementation of
> setjmp/longjmp, the custom classes that I added to handle them, and
> stepping through how exploded_node::on_stmt handles setjmp and longjmp
> calls, and what the resulting exploded_graph looks like (-fdump-
> analyzer-exploded-graph and -fdump-analyzer-supergraph), in that
> special-cased edges have to be created that weren't in the original
> CFGs or callgraph (for the interprocedural case).
>
> I think an implementation of exception-handling would look somewhat
> similar.
>
> Thanks, for all the r
Re: [GSoC-2021] Interested in project `Extend the static analysis pass`
On Tue, Mar 30, 2021 at 6:42 PM David Malcolm wrote:
> On Tue, 2021-03-30 at 16:06 +0530, Saloni Garg wrote:
> > On Sun, Mar 28, 2021 at 8:03 PM David Malcolm
> > wrote:
> >
> > > On Sun, 2021-03-28 at 18:06 +0530, Saloni Garg wrote:
> > > > Hi, I have tried the following examples with the fanalyzer option
> > > > in
> > > > g++.
> > > >
> > > > 1 (a)
> > > > void myFunction()
> > > > {
> > > > char *p =new char;
> > > > }
> > > > int main()
> > > > {
> > > >func();
> > > >return 0;
> > > > }
> > >
> > > BTW, are you familiar with Compiler Explorer (godbolt.org)? It's
> > > very
> > > handy for testing small snippets of code on different compilers and
> > > different compiler versions. Though I don't know how long the URLs
> > > are
> > > good for (in terms of how long code is cached for)
> > >
> > > Fixing up the name of the called function to "func":
> > > https://godbolt.org/z/TnM6n4xGc
> > > I get the leak report, as per RFE 94355. This warning looks
> > > correct,
> > > in that p does indeed leak.
> > >
> > > Hi, thanks for the effort, sorry for the typo. I now know about the
> > godbolt.org and it is certainly useful.
> >
> > > I should mention that the analyzer has some special-casing for
> > > "main",
> > > in that the user might not care about one-time leaks that occur
> > > within
> > > "main", or something only called directly by it; this doesn't seem
> > > to
> > > be the case here. If I remove the implementation to main, the
> > > analyzer
> > > still correctly complains about the leak:
> > > https://godbolt.org/z/zhK4vW6G8
> > >
> > > That's something new. I also didn't know that. I believe we can
> > > shift our
> > minimal example to just func() and remove main().
>
> Yes - simpler is better with such examples.
>
> (Occasionally it's helpful to have "main" so that the resulting code
> can be executed - especially under valgrind, as a check that something
> really is leaking - but a simpler reproducer is usually best when
> debugging)
>
> [...snip...]
>
Ok, I will keep this in mind. Thanks.
>
> > > I think an implementation of exception-handling would look somewhat
> > > similar.
> > >
> > > Thanks, for all the references to the code. I am new to GCC, so
> > > apologies
> > if I am a bit slow in understanding. I am trying to run and go
> > through all
> > the references that you gave me.
>
> Sorry if I'm overwhelming you with too much at once...
>
> ...and here's yet more information!
>
> I wrote this guide to getting started with hacking on GCC, aimed at
> newcomers to the project:
> https://dmalcolm.fedorapeople.org/gcc/newbies-guide/
>
> and in particular you may find the guide to debugging GCC useful:
> https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html
>
> FWIW I like to use
> -fanalyzer-dump-stderr
> when stepping through the analyzer in gdb, so that I can put
> breakpoints on what I'm interested in, but also have a log of the
> activity that happened between the breakpoints.
>
No, it's actually fun learning all this. Thank you for sharing all the
references. Although, I was already using gdb to travel inside the code.
>
> > > > Please, let me know your thoughts on this.
> > >
> > > Looks like you're making a great start.
> > >
> > Thanks for the feedback. In parallel, can I start working on the
> > Gsoc
> > proposal as well?
>
> Please do work on the formal proposal - without it we can't accept you
> as a GSoC student. The window for submitting proposals opened
> yesterday, and I believe it closes in a couple of weeks, and you need
> to do that, so any experimentation you do now should really just be in
> support of writing a good proposal. It would be a shame to not have a
> good prospective candidate because they didn't allow enough time to do
> the proper GSoC paperwork before the deadline.
>
Thanks for understanding. Here is an initial draft (
https://docs.google.com/document/d/1inkkU5B55s_FOWRzUuf38s7XEet65kc0dW3yFn0yh1M/edit?usp=sharing)
of my GSoC proposal. I am yet to fill in the missing blocks.
Please, let me know if you have any comments on the document itself.
>
> > I hope, we can get suggestions from the gcc community as
> > well once the things are written properly in a document.
>
> Indeed
>
> Hope this is constructive
> Dave
>
> [...snip...]
>
> I also request the GCC community also to please provide any suggestions
possible on the above-shared document.
-Saloni
Re: [GSoC-2021] Interested in project `Extend the static analysis pass`
Hi, apologies for the delayed reply. I was having some college commitments.
On Wed, Mar 31, 2021 at 11:22 PM David Malcolm wrote:
> On Wed, 2021-03-31 at 21:41 +0530, Saloni Garg wrote:
> > On Tue, Mar 30, 2021 at 6:42 PM David Malcolm
> > wrote:
> >
> > > On Tue, 2021-03-30 at 16:06 +0530, Saloni Garg wrote:
> > > > On Sun, Mar 28, 2021 at 8:03 PM David Malcolm <
> > > > dmalc...@redhat.com>
> > > > wrote:
>
> [...snip...]
>
> > > >
> > No, it's actually fun learning all this. Thank you for sharing all
> > the
> > references. Although, I was already using gdb to travel inside the
> > code.
>
> Great!
>
> > >
> > > > > > Please, let me know your thoughts on this.
> > > > >
> > > > > Looks like you're making a great start.
> > > > >
> > > > Thanks for the feedback. In parallel, can I start working on the
> > > > Gsoc
> > > > proposal as well?
> > >
> > > Please do work on the formal proposal - without it we can't accept
> > > you
> > > as a GSoC student. The window for submitting proposals opened
> > > yesterday, and I believe it closes in a couple of weeks, and you
> > > need
> > > to do that, so any experimentation you do now should really just be
> > > in
> > > support of writing a good proposal. It would be a shame to not
> > > have a
> > > good prospective candidate because they didn't allow enough time to
> > > do
> > > the proper GSoC paperwork before the deadline.
> > >
> > Thanks for understanding. Here is an initial draft (
> >
> >
> https://docs.google.com/document/d/1inkkU5B55s_FOWRzUuf38s7XEet65kc0dW3yFn0yh1M/edit?usp=sharing
> > )
> > of my GSoC proposal. I am yet to fill in the missing blocks.
> > Please, let me know if you have any comments on the document itself.
>
> Caveat: I'm not familiar with the expected format of such documents.
>
> Looks like a good first draft.
I don't think there is any such expected format(I checked some previous
years accepted proposals). I believe if we clearly write the expected goal
and the tentative approach to reach it, that would be okay for the proposal.
>
> Some notes:
> - maybe update the title to be more specific (i.e. that it's about
> extending the pass to support C++ exception-handling)
>
Done.
> - my email address is misspelled (missing the leading "d")
>
Really sorry. Done.
> - in Example 2, maybe spell out why it's a leak - when does the
> allocated buffer stop being referenceable?
>
Explained. Please let me know if you feel it has any loose ends.
> - you have a simple example of a false negative; is it possible to give
> a simple example of a false positive? (I think "new" is meant to raise
> an exception if it fails, so a diagnostics about a NULL-deref on
> unchecked new might be a false positive. I'm not sure)
>
I tried the following example:
#include
#include
using namespace std;
int *p;
int* alloc() {
return new int;
}
void free() {
delete p;
}
int main()
{
try {
p = alloc();
free();
} catch(...) {
}
return 0;
}
Please, have a look here (https://godbolt.org/z/8WvoaP67n). I believe it is
a false positive, I am not sure, please confirm.
> - maybe specify that this is exception-handling specifically for C++
> code (GCC supports many languages)
>
Done.
> - "sample example programs": for "sample" did you mean to write
> "simple" here?
>
By sample examples, I meant the test cases that shall be used to prove the
correctness of the patches during the course.
> - as well as understanding code, you'll need to understand data,
> specifically getting a feel for the kinds of control flow graphs that
> the analyzer is receiving as inputs i.e. what the analyzer "sees" when
> the user inputs various C++ language constructs; what interprocedural
> vs intraprocedural raise/try/catch situations look like, etc.
>
I am in the process to understand how the analyzer works. I believe I have
just got a gist of the approach being used. The gimple graph has been
processed in a Worklist manner. We analyze each statement and add
predecessors/successors if there is some new information coming out of the
analyzed statement. For example, In the memory leak examples discussed
here, if at a statement I see a *new *expression, then I need to add all
the nodes where this value can flow into, to find out a possible *free
*expression
to block the possible memory leak.
In the case of interprocedural, I need to incorporate the effects of any
function calls in between and see if it changes my analysis result or not.
Please, let me know if I am wrong somewhere.
-Saloni
>
> Hope this makes sense and is helpful
> Dave
>
>
Re: [GSoC-2021] Interested in project `Extend the static analysis pass`
On Thu, Apr 8, 2021 at 8:19 AM David Malcolm wrote:
> On Wed, 2021-04-07 at 01:59 +0530, Saloni Garg wrote:
> > Hi, apologies for the delayed reply. I was having some college
> > commitments.
> > On Wed, Mar 31, 2021 at 11:22 PM David Malcolm
> > wrote:
> >
> > > On Wed, 2021-03-31 at 21:41 +0530, Saloni Garg wrote:
> > > > On Tue, Mar 30, 2021 at 6:42 PM David Malcolm <
> > > > dmalc...@redhat.com>
> > > > wrote:
> > > >
> > > > > On Tue, 2021-03-30 at 16:06 +0530, Saloni Garg wrote:
> > > > > > On Sun, Mar 28, 2021 at 8:03 PM David Malcolm <
> > > > > > dmalc...@redhat.com>
> > > > > > wrote:
> > >
>
> [...snip...]
>
> > > > > Please do work on the formal proposal - without it we can't
> > > > > accept
> > > > > you
> > > > > as a GSoC student. The window for submitting proposals opened
> > > > > yesterday, and I believe it closes in a couple of weeks, and
> > > > > you
> > > > > need
> > > > > to do that, so any experimentation you do now should really
> > > > > just be
> > > > > in
> > > > > support of writing a good proposal. It would be a shame to not
> > > > > have a
> > > > > good prospective candidate because they didn't allow enough
> > > > > time to
> > > > > do
> > > > > the proper GSoC paperwork before the deadline.
> > > > >
> > > > Thanks for understanding. Here is an initial draft (
> > > >
> > > >
> > >
> > >
> https://docs.google.com/document/d/1inkkU5B55s_FOWRzUuf38s7XEet65kc0dW3yFn0yh1M/edit?usp=sharing
> > > > )
> > > > of my GSoC proposal. I am yet to fill in the missing blocks.
> > > > Please, let me know if you have any comments on the document
> > > > itself.
> > >
> > > Caveat: I'm not familiar with the expected format of such
> > > documents.
> > >
> > > Looks like a good first draft.
> >
> > I don't think there is any such expected format(I checked some
> > previous
> > years accepted proposals). I believe if we clearly write the expected
> > goal
> > and the tentative approach to reach it, that would be okay for the
> > proposal.
>
> Looking at:
> https://gcc.gnu.org/wiki/SummerOfCode#Application
> we don't have a specific format to be followed.
>
> That said, I saw this
> https://google.github.io/gsocguides/student/writing-a-proposal
> which seems to have useful advice to prospective GSoC students. In
> particular, the "Elements of a Quality Proposal" lists various things
> that in your current draft are missing, and which would strengthen your
> proposal. So I'd recommend that you (and other prospective GSoC
> candidates) have a look at that.
>
Added some new sections. Tried to explain them as well. There are some
things I am not clear about, so explicitly mentioned them and will add the
relevant explanations and present them in the later reports. Please let me
know if this sounds good to you and provide feedback as well.
>
> [...snip...]
>
> > > - in Example 2, maybe spell out why it's a leak - when does the
> > > allocated buffer stop being referenceable?
> > >
> > Explained. Please let me know if you feel it has any loose ends.
>
> I think the leak is actually at line 8, when the "catch" clause ends.
> Isn't the buffer passed into the exception-state of the thread, and
> becomes live during the "catch" clause, but stops being live at the end
> of the catch clause?
>
Yes, I understood your point and have added the same in the document as
well. The memory becomes unreferenced after the catch block ends so that is
basically the point where this leak started.
>
> >
> > > - you have a simple example of a false negative; is it possible to
> > > give
> > > a simple example of a false positive? (I think "new" is meant to
> > > raise
> > > an exception if it fails, so a diagnostics about a NULL-deref on
> > > unchecked new might be a false positive. I'm not sure)
> > >
> > I tried the following example:
> >
> > #include
> > #include
> > using namespace std;
> > int *p;
> > int* alloc() {
> >return new int;
> > }
> > void free() {
> >delete p;
> > }
>
> FWIW please don't create a top-level function called "free" that isn't
> the C stdlib's free, it's confusing!
>
Sorry, my bad renamed it to `myfree`.
>
> > int main()
> > {
> >try {
> > p = alloc();
> > free();
> >} catch(...) {
> >}
> >return 0;
> > }
> > Please, have a look here (https://godbolt.org/z/8WvoaP67n). I believe
> > it is
> > a false positive, I am not sure, please confirm.
>
> It looks like one to me. I had a look at -fdump-analyzer-exploded-
> graph and the false positive seems to be associated with the edge with
> the EH flag (to the catch handler).
>
I have understood the exploded graph but not able to understand the `EH
flag` point you are making, so I will get back to you on this.
>
> [...snip...]
>
> >
> > > - "sample example programs": for "sample" did you mean to write
> > > "simple" here?
> > >
> > By sample examples, I meant the test cases that shall be used to
> > prove the
> > correctness of the patches during the course.
>
> Isn't "sample examples" a tau
Re: [GSoC-2021] Interested in project `Extend the static analysis pass`
On Sun, Apr 11, 2021 at 12:14 AM David Malcolm wrote:
> On Sat, 2021-04-10 at 21:18 +0530, Saloni Garg wrote:
> > On Thu, Apr 8, 2021 at 8:19 AM David Malcolm
> > wrote:
> >
> > > On Wed, 2021-04-07 at 01:59 +0530, Saloni Garg wrote:
>
> [...]
>
> > > Looking at:
> > > https://gcc.gnu.org/wiki/SummerOfCode#Application
> > > we don't have a specific format to be followed.
> > >
> > > That said, I saw this
> > > https://google.github.io/gsocguides/student/writing-a-proposal
> > > which seems to have useful advice to prospective GSoC students. In
> > > particular, the "Elements of a Quality Proposal" lists various
> > > things
> > > that in your current draft are missing, and which would strengthen
> > > your
> > > proposal. So I'd recommend that you (and other prospective GSoC
> > > candidates) have a look at that.
> > >
> > Added some new sections. Tried to explain them as well. There are
> > some
> > things I am not clear about, so explicitly mentioned them and will
> > add the
> > relevant explanations and present them in the later reports. Please
> > let me
> > know if this sounds good to you and provide feedback as well.
>
> The updated version looks a lot stronger.
>
Hi, Thanks for the quick feedback.
>
> That said, you haven't given details of your programming expertise - in
> particular this project will require proficiency with C++, so a good
> application would give evidence to the reader that you're already up-
> to-speed on writing and debugging C++ (see the "Biographical
> Information" section in the guide I linked to above for more info).
>
Apologies, but I am a beginner in this area of compilers and static
analysis. I already know some C++ coding which I have used mostly in
Competitive coding competitions. I have been following this(
https://www.cse.iitk.ac.in/users/karkare/Courses/cs618/) course to
understand the nuances of the static analysis. I am confident that I can
write the C++ code that is required here and know how to use tools like
GDB, Valgrind to debug the C++ codes, but I don't have any good projects to
prove that right now. My college got stopped due to COVID-19 and hasn't
started yet properly, so I have been trying to learn most of the things
online only.
I hope you understand.
- Saloni
> [...snip...]
>
> > > FWIW please don't create a top-level function called "free" that
> > > isn't
> > > the C stdlib's free, it's confusing!
> > >
> > Sorry, my bad renamed it to `myfree`.
>
> Thanks!
>
> > >
> > > > int main()
> > > > {
> > > >try {
> > > > p = alloc();
> > > > free();
> > > >} catch(...) {
> > > >}
> > > >return 0;
> > > > }
> > > > Please, have a look here (https://godbolt.org/z/8WvoaP67n). I
> > > > believe
> > > > it is
> > > > a false positive, I am not sure, please confirm.
> > >
> > > It looks like one to me. I had a look at -fdump-analyzer-exploded-
> > > graph and the false positive seems to be associated with the edge
> > > with
> > > the EH flag (to the catch handler).
> > >
> > I have understood the exploded graph but not able to understand the
> > `EH
> > flag` point you are making, so I will get back to you on this.
>
> Edges in control flow graphs can have flags; see the various
> DEF_EDGE_FLAG in gcc/cfg-flags.def in the source tree, and in
> particular the "EH" flag.
>
> These flags are visible in the analyzer's supergraph - they should
> appear in the .dot dump files from the analyzer - so sometimes they're
> difficult to see, depending on how GraphViz lays things out. (FWIW I
> use:
> https://github.com/jrfonseca/xdot.py
> to view the .dot files; it's fast and convenient)
>
> [...snip...]
>
> >
> > > >
> > >
> > > Currently the analyzer has a "brute force" approach to
> > > interprocedural
> > > analysis, and attempts to simulate the calls and returns in a
> > > fairly
> > > direct way. It's crude (and has exponential growth), but is
> > > reasonably
> > > simple conceptually (or at least I think so). The analyzer
> > > implements
> > > setjmp/longjmp in a similar way, and exception-handling could be
> > > based
> > > on that code.
> > >
> > Going through that already and your comments at the start of every
> > data
> > structure defined are really helpful.
>
> Thanks!
>
> >
> [...snip...]
>
> Dave
>
>
Re: [GSoC-2021] Interested in project `Extend the static analysis pass`
On Mon, Apr 12, 2021 at 7:35 PM David Malcolm wrote: > On Sun, 2021-04-11 at 17:06 +0530, Saloni Garg wrote: > > On Sun, Apr 11, 2021 at 12:14 AM David Malcolm > > wrote: > > > > > On Sat, 2021-04-10 at 21:18 +0530, Saloni Garg wrote: > > > > On Thu, Apr 8, 2021 at 8:19 AM David Malcolm > > > > > > > > wrote: > > > > > > > > > On Wed, 2021-04-07 at 01:59 +0530, Saloni Garg wrote: > > > > > > [...] > > > > > > > > Looking at: > > > > > https://gcc.gnu.org/wiki/SummerOfCode#Application > > > > > we don't have a specific format to be followed. > > > > > > > > > > That said, I saw this > > > > > > > > > > https://google.github.io/gsocguides/student/writing-a-proposal > > > > > which seems to have useful advice to prospective GSoC > > > > > students. In > > > > > particular, the "Elements of a Quality Proposal" lists various > > > > > things > > > > > that in your current draft are missing, and which would > > > > > strengthen > > > > > your > > > > > proposal. So I'd recommend that you (and other prospective > > > > > GSoC > > > > > candidates) have a look at that. > > > > > > > > > Added some new sections. Tried to explain them as well. There are > > > > some > > > > things I am not clear about, so explicitly mentioned them and > > > > will > > > > add the > > > > relevant explanations and present them in the later reports. > > > > Please > > > > let me > > > > know if this sounds good to you and provide feedback as well. > > > > > > The updated version looks a lot stronger. > > > > > Hi, Thanks for the quick feedback. > > > > > > > > That said, you haven't given details of your programming expertise > > > - in > > > particular this project will require proficiency with C++, so a > > > good > > > application would give evidence to the reader that you're already > > > up- > > > to-speed on writing and debugging C++ (see the "Biographical > > > Information" section in the guide I linked to above for more info). > > > > > Apologies, but I am a beginner in this area of compilers and static > > analysis. I already know some C++ coding which I have used mostly in > > Competitive coding competitions. I have been following this( > > https://www.cse.iitk.ac.in/users/karkare/Courses/cs618/) course to > > understand the nuances of the static analysis. I am confident that I > > can > > write the C++ code that is required here and know how to use tools > > like > > GDB, Valgrind to debug the C++ codes, > > Your proposal would benefit from including something like the above. > > We're not expecting Bjarne Stroustrup levels of competence in C++, > especially considering that you are all students - but we need some > ability in C++... which you may already have, it's hard for me to tell > as the current draft proposal is written. Part of the point of GSoC is > to learn, but to learn about the specifics of the FLOSS project you > apply to [1], rather than the implementation language. > Yes, I have added the details related to C++ in the document. > > > but I don't have any good projects to > > prove that right now. My college got stopped due to COVID-19 and > > hasn't > > started yet properly, so I have been trying to learn most of the > > things > > online only. > > I hope you understand. > > Indeed. > > > Hope this is helpful; good luck (the deadline to apply is fast > approaching) > Thanks, I have submitted the final proposal. Now switching on to the coding part. - Saloni > [...snip...]
