On Thu, Feb 18, 2016 at 3:29 PM, Tom de Vries <tom_devr...@mentor.com> wrote: > On 17/02/16 14:42, Richard Biener wrote: >> >> On Wed, Feb 17, 2016 at 1:41 PM, Tom de Vries <tom_devr...@mentor.com> >> wrote: >>> >>> Hi, >>> >>> once in a while I'm in a gdb debug session debugging cc1, and want to >>> print >>> the current function to file. >>> >>> There's a debug function debug_function that prints a function to stderr, >>> and there are methods to redirect output of a command to a file ( >>> https://sourceware.org/gdb/onlinedocs/gdb/Logging-Output.html ). >>> >>> And there's a function dump_function_to_file that takes a FILE* >>> parameter, >>> which could be combined with open/close calls in gdb. >>> >>> But I think a short-hand is easier. >>> >>> This patch adds a function debug_function_to_file. It can f.i. be called >>> as: >>> ... >>> (gdb) call debug_function_to_file (cfun.decl, "foo.1.txt", 0) >>> ... >>> >>> Hmm, now I wonder if the order 'cfun.decl, 0, "foo.1.txt"' would make >>> more >>> sense (first two parameters the same as in debug_function). >>> >>> OK for stage1 trunk if bootstrap and reg-test succeeds? >> >> >> Bonus for making this a helper in gdbhooks.py instead, using >> fopen/fclose and the existing inferior calls. >> > > Using attached demonstrator patch, we can use command debug-function-to-file > in gdb: > ... > (gdb) python import sys; sys.path.append('<path>/gcc'); import gdbhooks > Successfully loaded GDB hooks for GCC > (gdb) b tail_merge_optimize > Breakpoint 1 at 0x11be1cc: file gcc/tree-ssa-tail-merge.c, line 1633. > (gdb) r > Starting program: cc1 -quiet hello.c -O2 -o hello.s > Breakpoint 1, tail_merge_optimize (todo=0) at gcc/tree-ssa-tail-merge.c:1633 > 1633 int nr_bbs_removed_total = 0; > (gdb) debug-function-to-file "bla.txt" > $1 = 47180688 > $2 = <function_decl 0x7ffff61a22a0 main> > $3 = 0 > ... > > and we find that bla.txt contains the result of dump_function_to_file: > ... > $ cat bla.txt > main () > { > <bb 2>: > __builtin_puts (&"hello"[0]); > return 0; > > } > ... > > I would be nice if we could avoid the ${1,2,3} printouts and value history > assignments, but I'm not sure how to do that. > > And given that we have a command with a variable amount of arguments, we > should try to handle different number of arguments, say these three giving > the same result: > - debug-function-to-file "bla.txt" > - debug-function-to-file "bla.txt" cfun->decl > - debug-function-to-file "bla.txt" cfun->decl dump_flags > Or perhaps 0 for flags by default, as in pcfun.
Thanks for the example. Still trying to figure out how to handle multi vs. one arg case. Looks like the argument is passed as string ... Anyway, below is a dot-fn command which will only require refactoring of print_graph_cfg in graph.c. It still lacks a way to specify dump flags w/o blowing up though ... Richard. class dot_fn(gdb.Command): """ """ def __init__(self): gdb.Command.__init__(self, 'dot-fn', gdb.COMMAND_USER) def invoke(self, arg, from_tty): gdb.execute("call popen(\"dot -Tx11\", \"w\")") fp = gdb.history (0) gdb.execute("call start_graph_dump ((FILE *)%u, \"<debug>\")" % fp) gdb.execute("call print_graph_cfg_1 ((FILE *)%u, %s)" % (fp, arg)) gdb.execute("call end_graph_dump ((FILE *)%u)" % fp) gdb.execute("call fflush ((FILE *)%u)" % fp) gdb.execute("call close (fileno ((FILE *)%u))" % fp) gdb.execute("call pclose ((FILE *)%u)" % fp) dot_fn() > Thanks, > - Tom