Re: introducing vrc :)

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2771 bytes --]

On Tue, Apr 19, 2022 at 04:39:13PM +0200, Paolo Bonzini wrote:
> Hi all,
> 
> a while ago I looked at tools that could be used too build a call graph.
> The simplest but most effective that I found was a small Perl program
> (called "egypt", which is rot13 for "rtlcg" aka RTL call graph) that used
> the GCC dumps to build the graph.
> 
> I have now rewritten it in Python and extended it with a lot of new
> functionality:
> 
> - consult compile_commands.json to find/build dumps automatically
> 
> - virtual (manually created) nodes and edges
> 
> - query call graph in addition to generating DOT file
> 
> - interactive mode with readline + completion
> 
> The name is unfortunately not rot13 anymore, it stands for visit RTL
> callgraph.
> 
> Here is an example (run vrc from the root build directory of QEMU):
> 
> 	# load files
> 	load libblock.fa.p/*.c.o
> 
> 	# introduce virtual edges corresponding to function pointers
> 	node BlockDriverState.bdrv_co_flush
> 	edge bdrv_co_flush BlockDriverState.bdrv_co_flush
> 	edge BlockDriverState.bdrv_co_flush blk_log_writes_co_do_file_flush
> 	edge BlockDriverState.bdrv_co_flush preallocate_co_flush
> 	edge BlockDriverState.bdrv_co_flush raw_co_invalidate_cache
> 	edge BlockDriverState.bdrv_co_flush cbw_co_flush
> 	edge BlockDriverState.bdrv_co_flush quorum_co_flush
> 	edge BlockDriverState.bdrv_co_flush throttle_co_flush
> 	edge BlockDriverState.bdrv_co_flush blkdebug_co_flush
> 	edge BlockDriverState.bdrv_co_flush blkverify_co_flush
> 	edge BlockDriverState.bdrv_co_flush bdrv_mirror_top_flush
> 	# apply filter
> 	only --callees bdrv_co_flush
> 	# draw graph
> 	dotty --files
> 
> The filtering functionality is a bit rough in the presence of mutual
> recursion, but hopefully this can be already useful to find the root calls
> of bdrv_*, which are the places where the graph lock has to be taken for
> read.  Continuing the previous example:
> 
> 	# apply another filter
> 	reset
> 	omit --callees bdrv_co_flush
> 	keep bdrv_co_flush
> 	# example of query
> 	callers bdrv_co_flush
> 
> already gives a reasonable answer (not entirely correct, but the actual
> analysis must be done on all callbacks at once):
> 
> 	qed_co_request -> bdrv_co_flush
> 	qed_need_check_timer_entry -> bdrv_co_flush
> 	blk_log_writes_co_log -> bdrv_co_flush
> 	bdrv_co_flush_entry -> bdrv_co_flush
> 	bdrv_co_flush -> bdrv_co_flush
> 	blk_co_do_flush -> bdrv_co_flush
> 	bdrv_driver_pwritev -> bdrv_co_flush
> 	blk_co_flush -> bdrv_co_flush
> 	bdrv_flush -> bdrv_co_flush
> 	bdrv_co_do_pwrite_zeroes -> bdrv_co_flush
> 	blk_aio_flush_entry -> bdrv_co_flush

Cool, thanks for sharing. I will keep this in mind when I need to
analyze call graphs.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]