> On 13-Jun-2021, at 8:22 PM, David Malcolm <dmalc...@redhat.com> wrote:
>
> On Sun, 2021-06-13 at 19:11 +0530, Ankur Saini wrote:
>>
>>
>>> On 08-Jun-2021, at 11:24 PM, David Malcolm <dmalc...@redhat.com
>>> <mailto:dmalc...@redhat.com>>
>>> wrote:
>>>
>>> Is there a URL for your branch?
>>
>> no, currently it only local branch on my machine. Should I upload it on
>> a hosting site ( like GitHub ) ? or can I create a branch on remote
>> also ?
>
> At some point we want you to be able to push patches to trunk, so as a
> step towards that I think it would be good for you to have a personal
> branch on the gcc git repository.
>
> A guide to getting access is here:
> https://gcc.gnu.org/gitwrite.html <https://gcc.gnu.org/gitwrite.html>
>
> I will sponsor you.
I have filled the form.
>
>>
>>> The issue is that the analyzer currently divides calls into
>>> (a) calls where GCC's middle-end "knows" which function is called,
>>> and
>>> thus the call site has a cgraph_node.
>>> (b) calls where GCC's middle-end doesn't "know" which function is
>>> called.
>>>
>>> The analyzer handles
>>> (a) by building call and return edges in the supergraph, and
>>> processing them, and
>>> (b) with an "unknown call" handler, which conservatively sets lots
>>> of
>>> state to "unknown" to handle the effects of an arbitrary call, and
>>> where the call doesn't get its own exploded_edge.
>>
>>>
>>> In this bug we have a variant of (b), let's call it (c): GCC's
>>> middle-
>>> end doesn't know which function is called, but the analyzer's
>>> region_model *does* know at a particular exploded_node.
>>
>> but how will the we know this at the time of creation of supergraph?
>> isn’t exploded graph and regional model created after the supergraph ?
>
> You are correct.
>
> What I'm thinking is that when we create the supergraph we should split
> the nodes at more calls, not just at those calls that have a
> cgraph_edge, but also at those that are calls to an unknown function
> pointer (or maybe even split them at *all* calls).
>
> Then, later, when engine.cc <http://engine.cc/> is building the
> exploded_graph, the
> supergraph will have a superedge for those calls, and we can create an
> exploded_edge representing the call. That way if we discover the
> function pointer then (rather than having it from a cgraph_edge), we
> can build exploded nodes and exploded edges that are similar to the "we
> had a cgraph_edge" case. You may need to generalize some of the event-
> handling code to do this.
>
> Does that make sense?
>
> You might want to try building some really simple examples of this, to
> make it as easy as possible to see what's happening, and to debug.
ok let me see what can I do.
[...]
> Great.
>
> Let me know how you get on.
>
> As I understand it, Google recommends that we're exchanging emails
> about our GSoC project at least two times a week, so please do continue
> to report in, whether you're making progress, or if you feel you're
> stuck on something.
ok I would be more active from now on.
—
btw while using the gdb on “xgcc”, for some reason, debugger is not tracing the
call to "run_checkers()” and is directly jumping from
"pass_analyzer::execute()” to some instruction inside
"ana::dump_analyzer_json()”.
I am invoking debugger like this :-
—
$ ./xgcc /Users/ankursaini/Desktop/test.c -fanalyzer -B . -wrapper gdb,—args
—
and then while putting a breakpoint on “ana::run_checkers()”, gdb places 2
breakpoints ( one on correct position and another weirdly inside a different
function in the same file )
—
(gdb) br ana::run_checkers()
Breakpoint 3 at 0x101640990 (2 locations)
(gdb) info br
Num Type Disp Enb Address What
1 breakpoint keep y 0x000000010174ade7 in fancy_abort(char const*,
int, char const*) at ../../gcc-source/gcc/diagnostic.c:1915
2 breakpoint keep y 0x000000010174ee01 in internal_error(char
const*, ...) at ../../gcc-source/gcc/diagnostic.c:1835
3 breakpoint keep y <MULTIPLE>
3.1 y 0x0000000101640990
<ana::dump_analyzer_json(ana::supergraph const&, ana::exploded_graph const&)+48>
3.2 y 0x0000000101640ba0 in
ana::run_checkers() at ../../gcc-source/gcc/analyzer/engine.cc:4918
<http://engine.cc:4918/>
—
but during the execution it only hits the breakpoint 3.1 ( which is inside the
function "ana::dump_analyzer_json()” which according to me is called during the
execution of "impl_run_checkers()”, after completing the analysis to dump the
results in json format )
after looking at backtrace, I could see it calling "pass_analyzer::execute()”
where “run_checkers()” should be called, but no such call (or a call to
"impl_run_checkers()”) is seen there .
here is the backtrace when debugger hits this breakpoint 3.1
—
(gdb) c
Continuing.
[New Thread 0x1c17 of process 2392]
Thread 2 hit Breakpoint 3, 0x0000000101640990 in ana::dump_analyzer_json
(sg=..., eg=...) at ../../gcc-source/gcc/analyzer/engine.cc:4751
4751 char *filename = concat (dump_base_name, ".analyzer.json.gz", NULL);
(gdb) bt
#0 0x0000000101640990 in ana::dump_analyzer_json (sg=..., eg=...) at
../../gcc-source/gcc/analyzer/engine.cc:4751
#1 0x000000010161a919 in (anonymous namespace)::pass_analyzer::execute
(this=0x142b0a660) at ../../gcc-source/gcc/analyzer/analyzer-pass.cc:87
#2 0x000000010106319c in execute_one_pass (pass=<optimized out>,
pass@entry=<opt_pass* 0x0>) at ../../gcc-source/gcc/passes.c:2567
#3 0x0000000101064e1c in execute_ipa_pass_list (pass=<opt_pass* 0x0>) at
../../gcc-source/gcc/passes.c:2996
#4 0x0000000100a89065 in symbol_table::output_weakrefs (this=<optimized out>)
at ../../gcc-source/gcc/cgraphunit.c:2262
#5 0x0000000102038600 in ?? ()
#6 0x0000000000000000 in ?? ()
—
but at the end I can see the analyzer doing it’s work and generating the
required warning as intended.
I never used to experience this problem earlier when using debugger on a full
bootstrapped build. Looks like I am missing something here.
Thanks,
- Ankur
