From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id 8389C3860C32 for ; Mon, 28 Jun 2021 14:53:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8389C3860C32 Received: by mail-pg1-x533.google.com with SMTP id e33so15690302pgm.3 for ; Mon, 28 Jun 2021 07:53: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:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4Ip5XEr/VRbY7m/IFXMa8fT2pM1CWzbWFfWybGpETa8=; b=hUUZ22EIWxmqr3JqsiMqUrD0BSa4JvOdt3r9hOX018+hTVSfyu07GCcP3gAGel2LBe AHIDocnzrRCNS9FLi1NfqJ0CeSfMZrYdSmjGFY3vp4eOcG8ETY29UQumPYYoBJA9VfGa osE4KiyNblfEbpcU2lNCUfSELQdiysT7+WP0LC1qjjlXcO7DciewDuFlV66TpyxnIhnp dS0ULHVtAzMEIBHhOR/zG6S6bzlaUkhQQZ5A9Lbkw1LYZb1P+18HN53Il92wBI+Iww3n W6g5BEXwwlpJSpJJxFfwaWsyp8YpmC1gHom/7A5FoImgtFbmMxHUpOdbzi69BlLva85G LG5w== X-Gm-Message-State: AOAM531A7qQl0d6tyBQR3gfJK0qZ7MBkkyeSUfFdhIYmeJlxmlhc3Nuh nI2+yVrh2/uSSqdEFzZzW04= X-Google-Smtp-Source: ABdhPJxKs/dZ0fBeg4/p2HsBAPgruIGjK364Q4Gox65auMDRY5yt9Anw+Wk8i3alJ5dWOf33SbGtBA== X-Received: by 2002:a62:7cc4:0:b029:302:f75a:69ab with SMTP id x187-20020a627cc40000b0290302f75a69abmr25524422pfc.74.1624892026558; Mon, 28 Jun 2021 07:53:46 -0700 (PDT) Received: from [192.168.100.6] ([103.214.61.169]) by smtp.gmail.com with ESMTPSA id 23sm14411398pjw.28.2021.06.28.07.53.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Jun 2021 07:53:46 -0700 (PDT) From: Ankur Saini Message-Id: Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) Subject: Re: daily report on extending static analyzer project [GSoC] Date: Mon, 28 Jun 2021 20:23:41 +0530 In-Reply-To: <425d5e711663bbf0c1ebcfe05097780ebb2126a0.camel@redhat.com> Cc: gcc@gcc.gnu.org To: David Malcolm References: <35A0246A-D4F8-4B41-A009-4A98F78E0395@gmail.com> <06DBCE04-B3AC-4091-979D-430507352213@gmail.com> <425d5e711663bbf0c1ebcfe05097780ebb2126a0.camel@redhat.com> X-Mailer: Apple Mail (2.3654.20.0.2.21) X-Spam-Status: No, score=2.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Mon, 28 Jun 2021 14:53:49 -0000 > On 28-Jun-2021, at 12:18 AM, David Malcolm = wrote: >>=20 >>>=20 >>>>=20 >>>> Q. But even if we find out which function to call, how will the >>>> analyzer know which snode does that function belong ? >>>=20 >>> 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. >>>=20 >>> You can get the function * from a fndecl via DECL_STRUCT_FUNCTION. >>=20 >> so once we get fndecl, it should be comparatively smooth sailing from >> there.=20 >>=20 >> My attempt to get the value of function pointer from the state : - >>=20 >> - to access the region model of the state, I tried to access >> =E2=80=9Cm_region_model=E2=80=9D 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=E2=80=99t seem to find the fitting one. ( the closest I = could find >> was =E2=80=9Cregion_model::get_reachable_svalues()=E2=80=9D to get a = set of all the >> svalues reachable from that model ) >=20 > 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. >=20 > 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. >=20 > 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? shouldn=E2=80=99t the fn_decl should still have a cgraph_node if the = function is declared in the program itself ? it should just not have an = edge representing the call. Because I was able to find the super-graph node just with the help of = the function itself. this is how the function looks "exploded_node::on_edge()" right now. File: {$SCR_DIR}/gcc/analyzer/engine.cc 1305: bool 1306: exploded_node::on_edge (exploded_graph &eg, 1307: const superedge *succ, 1308: program_point *next_point, 1309: program_state *next_state, 1310: uncertainty_t *uncertainty) 1311: { 1312: LOG_FUNC (eg.get_logger ()); 1313:=20 1314: if (succ->m_kind =3D=3D SUPEREDGE_INTRAPROCEDURAL_CALL) 1315: { =20 1316: const program_point *this_point =3D &this->get_point(); 1317: const program_state *this_state =3D &this->get_state (); 1318: const gcall *call =3D this_point->get_supernode = ()->get_final_call (); =20 1319:=20 1320: impl_region_model_context ctxt (eg,=20 1321: this,=20 1322: this_state,=20 1323: next_state,=20 1324: uncertainty, 1325: this_point->get_stmt()); 1326:=20 1327: region_model *model =3D this_state->m_region_model; 1328: tree fn_decl =3D model->get_fndecl_for_call(call,&ctxt); 1329: if(DECL_STRUCT_FUNCTION(fn_decl)) 1330: { 1331: const supergraph *sg =3D &eg.get_supergraph(); 1332: supernode * sn =3D sg->get_node_for_function_entry = (DECL_STRUCT_FUNCTION(fn_decl)); 1333: // create enode and eedge ? 1334: } 1335: } 1336:=20 1337: if (!next_point->on_edge (eg, succ)) 1338: return false; 1339:=20 1340: if (!next_state->on_edge (eg, this, succ, uncertainty)) 1341: return false; 1342:=20 1343: return true; 1344: } for now, it is also detecting calls that already have call_sedge = connecting them, so I think I also have to filter them out. >=20 > Hope this is helpful > Dave Thanks=20 - Ankur