On 18/02/16 16:10, Richard Biener wrote:
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.
>
Using gdb.parse_and_eval does the trick.
>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 ...
https://sourceware.org/gdb/current/onlinedocs/gdb/Commands-In-Python.html#Commands-In-Python
:
...
— Function: Command.invoke (argument, from_tty)
...
To break argument up into an argv-like string use
gdb.string_to_argv. This function behaves identically to gdb's internal
argument lexer buildargv. It is recommended to use this for consistency.
Arguments are separated by spaces and may be quoted. Example:
print gdb.string_to_argv ("1 2\ \\\"3 '4 \"5' \"6 '7\"")
['1', '2 "3', '4 "5', "6 '7"]
...
Thanks,
- Tom
