🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.gcc.help
Article #50327

Static analysis of g++ call flow

#50327
From: Will Duncan
Date: Fri, 08 Oct 1993 14:19
60 lines
2677 bytes
  We are trying to use the output produced/generated from the flow analysis
phase of the compile to develop a kind of static call tree of our code. 
The flow analysis is what ends up in the ``file.flow'' when specifying: 

  g++ -df file.cc 

  The problem we've been having is that we don't always see a 1-to-1 relation
between the method invocations (function calls) in the .cc file and the
call_insn in the .flow file.   The help we would like is:

  - what should be be looking for in the flow and/or in the rtl to indicate the
    calls?   What we are doing now using awk to extact (from the .flow) as
    follows: 

/^;; Function/ {		# this is to save the function name 
	print "_"$3;
}

#     Then we look for the call_insn and save the called function, indenting a
#     TAB to align them inside and under the Function from above
   
/^\(call_insn/,/^$/ {
	if ($1 == "(call") {
		n = match($4, "[a-zA-Z0-9_]+");
		print "\t_" substr($4, n, RLENGTH);
	}
}

	So what we get ends up looking like this (after a run through g++filt):

auth_resolve_type(Dir_proxy *&, Type_proxy *&)
	_strcpy
	_33
	Debug_log::log_test(int)
	___builtin_new
	Record::Record(char)


  - if a method is invoked more than once within a given scope in the .cc file
    does it appear the same number of times in the .flow? 

    What we have observed is that in some cases a call_insn for a give method 
    doesn't appear at all.   The one case we are  tracking is the invocation of
    a method on an instance of a class passed to the routine/function as
    follows:

auth_resolve_type(Dir_proxy *&dir_var, Type_proxy *&type_var)

    the invocations on dir_var don't appear in the flow (i.e. 
    dir_var->do_something()  in the .cc never appears explicitly as a call_insn
    in the .flow.

    additional note ... the Dir_proxy class is in a library that of course gets
    pulled in at link/load time, maybe that's the problem.

This is pretty long winded but I think you get the picture of what we are trying
to do and what has been observed.

--will d.
Technical Details
Message-ID: <9310081415.AA10678@TIS.COM>
Path: arc1-ca.pugleaf.net!gmd.de!xlink.net!howland.reston.ans.net!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!cis.ohio-state.edu!tis.com!will

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 11318c,b96c32e932f5d2d3,start
X-Google-Attributes: gid11318c,public
X-Google-ArrivalTime: 1993-10-08 07:29:43 PST
Path: arc1-ca.pugleaf.net!gmd.de!xlink.net!howland.reston.ans.net!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!cis.ohio-state.edu!tis.com!will
From: will@tis.com (Will Duncan)
Newsgroups: gnu.gcc.help
Subject: Static analysis of g++ call flow
Date: 8 Oct 1993 10:19:28 -0400
Organization: GNUs Not Usenet
Lines: 60
Sender: daemon@cis.ohio-state.edu
Distribution: gnu
Message-ID: <9310081415.AA10678@TIS.COM>