From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124944 invoked by alias); 9 Nov 2016 13:59:28 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 124299 invoked by uid 89); 9 Nov 2016 13:59:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=hung, HTo:U*kevin, kevin, tst X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 Nov 2016 13:59:16 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EBA87C04D2A4; Wed, 9 Nov 2016 13:59:14 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uA9DxDZ7003210; Wed, 9 Nov 2016 08:59:13 -0500 Subject: Re: [PATCH v2 1/5] Extend test gdb.python/py-recurse-unwind.exp To: Kevin Buettner , gdb-patches@sourceware.org References: <20161102151111.2462c806@pinnacle.lan> <20161102151428.11d1d20e@pinnacle.lan> From: Pedro Alves Message-ID: <75c10343-bc79-42ff-5e8d-c6825dd89d22@redhat.com> Date: Wed, 09 Nov 2016 13:59:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20161102151428.11d1d20e@pinnacle.lan> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00214.txt.bz2 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