Re: [PATCH v2 1/5] Extend test gdb.python/py-recurse-unwind.exp

[Pedro Alves <palves at redhat dot com>]

On 11/02/2016 10:14 PM, Kevin Buettner wrote:
> This patch modifies the unwinder (sniffer) defined in
> py-recurse-unwind.py so that, depending upon the value of one of its
> class variables, it will take different paths through the code,
> testing different functionality.
> 
> The original test attempted to obtain the value of an undefined
> symbol.
> 
> This somewhat expanded test checks to see if 'pc' can be read via
> gdb.PendingFrame.read_register() and also via gdb.parse_and_eval().
> 
> gdb/testsuite/ChangeLog:
>     
>     	* gdb.python/py-recurse-unwind.c (ccc): Delete.
>     	(ccc0, ccc1, ccc2): New functions.
>     	(bbb): Call ccc0, ccc1, and ccc2.
>     	* gdb.python/py-recurse-unwind.py (TestUnwinder): Add calls
>     	to read_register() and gdb.parse_and_eval().  Make each code
>     	call a separate case that can be individually tested.
>     	* gdb.python/py-recurse-unwind.exp (cont_and_backtrace): New
>     	proc. Call cont_and_backtrace for each of the code paths that
>     	we want to test in the unwinder.
> ---
>  gdb/testsuite/gdb.python/py-recurse-unwind.c   | 16 ++++++-
>  gdb/testsuite/gdb.python/py-recurse-unwind.exp | 61 ++++++++++++++++----------
>  gdb/testsuite/gdb.python/py-recurse-unwind.py  | 29 +++++++++---
>  3 files changed, 76 insertions(+), 30 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.python/py-recurse-unwind.c b/gdb/testsuite/gdb.python/py-recurse-unwind.c
> index 02a835a..bd0330a 100644
> --- a/gdb/testsuite/gdb.python/py-recurse-unwind.c
> +++ b/gdb/testsuite/gdb.python/py-recurse-unwind.c
> @@ -18,14 +18,26 @@
>  /* This is the test program loaded into GDB by the py-recurse-unwind test.  */
>  
>  void
> -ccc (int arg)
> +ccc0 (int arg)
> +{
> +}
> +
> +void
> +ccc1 (int arg)
> +{
> +}
> +
> +void
> +ccc2 (int arg)
>  {
>  }
>  
>  void
>  bbb (int arg)
>  {
> -  ccc (789);
> +  ccc0 (789);
> +  ccc1 (789);
> +  ccc2 (789);
>  }
>  

Do we need separate functions?  You could do that with a
single function by making main call the same function more
than once, in a loop or unrolled, so that you don't need to
keep adding functions.  Or do with without continuing the
inferior, even, by using gdb's "flushregs" command.
Or was that to make sure test messages are unique below?

> +proc cont_and_backtrace { tst func } {
> +
> +    gdb_breakpoint "$func"
> +
> +    # We're testing different code paths within the unwinder's sniffer.
> +    # Set the current path to be tested here.
> +    gdb_test_no_output "python TestUnwinder.set_test(\"$tst\")" \
> +                       "set code path within python unwinder to $tst"
> +
> +    # If the unwinder is active, the usage count will increment while
> +    # running to the breakpoint.  Reset it prior to doing the backtrace.
> +    gdb_test_no_output "python TestUnwinder.reset_count()" \
> +                       "reset count for $tst"
> +
> +    gdb_continue_to_breakpoint "$func"
> +
> +    # The python based unwinder should be called a number of times while
> +    # generating the backtrace, but its sniffer always returns None.  So
> +    # it doesn't really contribute to generating any of the frames below.
> +    #
> +    # But that's okay.  Our goal here is to make sure that GDB doesn't
> +    # get hung up in potentially infinite recursion when invoking the
> +    # Python-based unwinder.
> +
> +    gdb_test_sequence "bt"  "backtrace for $tst" {
> +	"\\r\\n#0 .* ccc. \\(arg=789\\) at "
> +	"\\r\\n#1 .* bbb \\(arg=456\\) at "
> +	"\\r\\n#2 .* aaa \\(arg=123\\) at "
> +	"\\r\\n#3 .* main \\(.*\\) at"
> +    }
> +
> +    # Test that the python-based unwinder / sniffer was actually called
> +    # during generation of the backtrace.
> +    gdb_test "python print(TestUnwinder.count > 0)" "True" \
> +             "python unwinder called for $tst"
>  }

I would suggest using "with_test_prefix $tst" instead of manually
adding $tst.  The gdb_breakpoint / gdb_continue_to_breakpoint
calls don't include $tst, and while currently you'll end up with
unique test messages due the unique function names, that seems
like fragility easily avoided.

Otherwise, LGTM.

Thanks,
Pedro Alves