From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id E9B173858023 for ; Sun, 27 Jun 2021 18:48:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E9B173858023 Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-458-L1Mul6VfN_6QxRldcGOaIg-1; Sun, 27 Jun 2021 14:48:47 -0400 X-MC-Unique: L1Mul6VfN_6QxRldcGOaIg-1 Received: by mail-qt1-f198.google.com with SMTP id l2-20020ac84cc20000b029024ef0325fd0so10342424qtv.0 for ; Sun, 27 Jun 2021 11:48:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=Pm32WHfnF6h+uahjg1uzYsQdS3YqrqMkB/oo8fYrjkE=; b=uDcBBDJnDryJqt7hnK8iWO1DaOb1SbIHWyqpuugcT6uQUuzZj7MKfbsJDacwLWTdty tAs2HlRtvCb9gtUHWX+twzHp1s3X9yvg2p79tDlMgmvjxYx/W38zN0c5ZLRp/q48zt6m huPnTSK2HOLnAABNSwf4eN0EKbA3tWwJHN7+Xy1tNmWxuUQXTFbeyy3cnW+3/tw8S0cl tRY33CeKj4jssJFjGLh993r2bqyzaJLlGYULiN2rdJyDvD2vXxgPu4kVSQZP5Hb3m7i6 5sMbBtRUMm5Kf8RnpjGpQ7d7fHQApsptCoETgMxafjf6ed5jOTtcdQFYmiX30prkZq7r Nakw== X-Gm-Message-State: AOAM531fcCPCsp4pDUUJjXovNtI9oDdqpf4je0PG0Kazt7jiAa/4F+gs RvH5Q//QaFBCFHi1HdVWxkKTMfQ7xS10r9+yP5IF90gth17HJhDC8Qja2GNJkjDpbFU08QB4jV6 uXXaoW5k= X-Received: by 2002:a37:7485:: with SMTP id p127mr21828846qkc.323.1624819727107; Sun, 27 Jun 2021 11:48:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyF+vyq2Bs1gApdrVmlJSq3puEFzGWQyYROSUbDJAbN/nL31wJQiTCARGMdAsmI7YSREm/27g== X-Received: by 2002:a37:7485:: with SMTP id p127mr21828829qkc.323.1624819726835; Sun, 27 Jun 2021 11:48:46 -0700 (PDT) Received: from t14s.localdomain (c-73-69-212-193.hsd1.nh.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id l1sm4784966qkc.93.2021.06.27.11.48.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 27 Jun 2021 11:48:46 -0700 (PDT) Message-ID: <425d5e711663bbf0c1ebcfe05097780ebb2126a0.camel@redhat.com> Subject: Re: daily report on extending static analyzer project [GSoC] From: David Malcolm To: Ankur Saini Cc: gcc@gcc.gnu.org Date: Sun, 27 Jun 2021 14:48:44 -0400 In-Reply-To: <06DBCE04-B3AC-4091-979D-430507352213@gmail.com> References: <35A0246A-D4F8-4B41-A009-4A98F78E0395@gmail.com> <06DBCE04-B3AC-4091-979D-430507352213@gmail.com> User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2021 18:48:51 -0000 On Sat, 2021-06-26 at 20:50 +0530, Ankur Saini wrote: > > > On 25-Jun-2021, at 9:04 PM, David Malcolm > > wrote: > > > > On Fri, 2021-06-25 at 20:33 +0530, Ankur Saini wrote: > > > AIM for today : > > > > > > - try to create an intra-procedural link between the calls the > > > calling > > > and returning snodes > > > - figure out the program point where exploded graph would know > > > about > > > the function calls > > > - figure out how the exploded node will know which function to > > > call > > > - create enodes and eedges for the calls > > > > > > — > > > > > > PROGRESS : > > > > > > - I created an intraprocedural link between where the the > > > splitting is happening to connect the call and returning snodes. > > > like this :- > > > > > > (in supergraph.cc at "supergraph::supergraph (logger *logger)" ) > > > ``` > > > 185             if (cgraph_edge *edge = supergraph_call_edge > > > (fun, stmt)) > > > 186             { > > > 187                m_cgraph_edge_to_caller_prev_node.put(edge, > > > node_for_stmts); > > > 188                node_for_stmts = add_node (fun, bb, as_a > > > (stmt), NULL); > > > 189                m_cgraph_edge_to_caller_next_node.put (edge, > > > node_for_stmts); > > > 190             } > > > 191             else > > > 192             { > > > 193               gcall *call = dyn_cast (stmt); > > > 194               if (call) > > > 195               { > > > 196                 supernode *old_node_for_stmts = > > > node_for_stmts; > > > 197                 node_for_stmts = add_node (fun, bb, as_a > > > (stmt), NULL); > >                                                          > > ^^^^^^^^^^^^^^^^^^^^^ > > Given the dyn_cast of stmt to gcall * at line 193 you can use > > "call" > > here, without the as_a cast, as you've already got "stmt" as a > > gcall * > > as tline 193. > > ok > > > > > You might need to add a hash_map recording the mapping from such > > stmts > > to the edges, like line 189 does.  I'm not sure, but you may need > > it > > later. > > but the node is being created if there is no cgraph_edge > corresponding to the call, so to what edge will I map > “node_for_stmts" to ? Sorry; I think I got confused. Re-reading this part of my email, it doesn't make sense to me. Sorry. [...snip...] > > > > > > > > > > Q. But even if we find out which function to call, how will the > > > analyzer know which snode does that function belong ? > > > > Use this method of supergraph: > >  supernode *get_node_for_function_entry (function *fun) const; > > to get the supernode for the entrypoint of a given function. > > > > You can get the function * from a fndecl via DECL_STRUCT_FUNCTION. > > so once we get fndecl, it should be comparatively smooth sailing from > there. > > My attempt to get the value of function pointer from the state : - > > - to access the region model of the state, I tried to access > “m_region_model” of that state. > - now I want to access cluster for a function pointer. > - but when looking at the accessible functions to region model class, > I couldn’t seem to find the fitting one. ( the closest I could find > was “region_model::get_reachable_svalues()” to get a set of all the > svalues reachable from that model ) In general you can use: region_model::get_rvalue to go from a tree to a symbolic value for what the analyzer "thinks" the value of that tree is at that point along the path. If it "knows" that it's a specific function pointer, then IIRC this will return a region_svalue where region_svalue::get_pointee () will (hopefully) point at the function_region representing the memory holding the code of the function. function_region::get_fndecl should then give you the tree for the specific FUNCTION_DECL, from which you can find the supergraph node etc. It looks like region_model::get_fndecl_for_call might already do most of what you need, but it looks like it bails out for the "NULL cgraph_node" case. Maybe that needs fixing, so that it returns the fndecl for that case? That already gets used in some places, so maybe try putting a breakpoint on that and see if fixing that gets you further? Hope this is helpful Dave