From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24501 invoked by alias); 7 Sep 2004 14:12:00 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 24491 invoked from network); 7 Sep 2004 14:11:59 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 7 Sep 2004 14:11:59 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i87EBsS2001497 for ; Tue, 7 Sep 2004 10:11:59 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i87EBl309863; Tue, 7 Sep 2004 10:11:52 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id ED08B28D2; Tue, 7 Sep 2004 10:11:42 -0400 (EDT) Message-ID: <413DC19E.2030209@gnu.org> Date: Tue, 07 Sep 2004 14:12:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040831 MIME-Version: 1.0 To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa] Gut signals.exp References: <412B5C86.2090607@gnu.org> In-Reply-To: <412B5C86.2090607@gnu.org> Content-Type: multipart/mixed; boundary="------------020108070607000306050203" X-SW-Source: 2004-09/txt/msg00106.txt.bz2 This is a multi-part message in MIME format. --------------020108070607000306050203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 5 Ping --------------020108070607000306050203 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message" Content-length: 8175 Return-Path: Delivered-To: cagney@localhost.redhat.com Received: from localhost (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 008C02B9D for ; Tue, 24 Aug 2004 11:22:51 -0400 (EDT) Envelope-to: cagney@gnu.org Delivery-date: Tue, 24 Aug 2004 11:21:03 -0400 Received: from fencepost.gnu.org by localhost with IMAP (fetchmail-6.2.4) for cagney@localhost (single-drop); Tue, 24 Aug 2004 11:22:52 -0400 (EDT) Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1Bzd6d-0007FN-Hr for cagney@gnu.org; Tue, 24 Aug 2004 11:21:03 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1Bzd6T-0001nU-6J for cagney@gnu.org; Tue, 24 Aug 2004 11:20:54 -0400 Received: from [66.187.233.31] (helo=mx1.redhat.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1Bzd6S-0001nG-J9 for cagney@gnu.org; Tue, 24 Aug 2004 11:20:53 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i7OFKkS0032495 for ; Tue, 24 Aug 2004 11:20:46 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i7OFKja27687; Tue, 24 Aug 2004 11:20:45 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id B38B92B9D; Tue, 24 Aug 2004 11:19:34 -0400 (EDT) Message-ID: <412B5C86.2090607@gnu.org> Date: Tue, 24 Aug 2004 11:19:34 -0400 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040801 X-Accept-Language: en, en-us MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: [rfa] Gut signals.exp Content-Type: multipart/mixed; boundary="------------080502030805020708050603" X-Spam-Status: No, hits=0.4 required=5.0 tests=RCVD_IN_ORBS,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) This is a multi-part message in MIME format. --------------080502030805020708050603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 956 Hello, The attached patch removes from signals.exp any tests covered by sigstep.exp (I'm assuming that my sigstep.exp patch is approved). This leaves one test (forcing a signal delivery), and for that, I merged it with a weaker but equivalent test found at the end of the .exp file. The only interesting bit [well I think] is that I'm also removing several xfails. The xfailed test (it should have been a kfail) is checking that GDB remembers that it was single-stepping, so that when a signal handler breakpoint is hit and then continued, GDB resumes the earlier single-step task. Making this work would involve a stack of outstanding commands and would require a very good UI design. Consequently, I think the feature & test can be dropped until someone is motivated to design / implement it. I have ensured that sigstep.exp tests a related case - step/next working correctly when skipping a handler. ok? Andrew PS: `fixed' PPC NetBSD --------------080502030805020708050603 Content-Type: text/plain; name="diffs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diffs" Content-length: 4734 2004-08-24 Andrew Cagney * gdb.base/signals.exp (signal_tests_1): Delete. Merge signal delivery test with duplicate at end of file. Index: testsuite/gdb.base/signals.exp =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.base/signals.exp,v retrieving revision 1.9 diff -p -u -r1.9 signals.exp --- testsuite/gdb.base/signals.exp 9 Aug 2004 13:17:34 -0000 1.9 +++ testsuite/gdb.base/signals.exp 24 Aug 2004 14:58:11 -0000 @@ -45,116 +45,6 @@ if {$hp_cc_compiler} { set void void } -proc signal_tests_1 {} { - global gdb_prompt - if [runto_main] then { - gdb_test "next" "signal \\(SIGUSR1.*" \ - "next over signal call; SIGALRM handler" - gdb_test "next" "alarm \\(.*" \ - "next over signal call; SIGUSR1 handler" - - # Set up an alarm, wait for it to be come pending then do a - # next to see what happens. - - gdb_test "next" "\\+\\+count; /\\* first \\*/" \ - "next over 1st alarm" - sleep 2 - gdb_test "next" "alarm .*" \ - "next over first count and SIGALRM to 2nd alarm" - - # Now do the same thing but with a breakpoint in the SIGALRM - # handler so that we stop there. - - gdb_test "break handler" "Breakpoint \[0-9\]+ .*" - gdb_test "next" "\\+\\+count; /\\* second \\*/" \ - "next over 2nd alarm" - sleep 2 - gdb_test "next" "Breakpoint.*handler.*" \ - "next over second count, but jump to handler" - gdb_test "backtrace" \ - "#0.*handler.*#1.*signal handler.*#2.* main .*" \ - "backtrace for 2nd alarm" - - # Let the signal handler return allowing main to advance to - # func1. - - gdb_test "break func1" "Breakpoint \[0-9\]+ .*" - gdb_test "break func2" "Breakpoint \[0-9\]+ .*" - gdb_test "continue" "Breakpoint.*func1.*" "continue to func1" - - # While still in func1, force a signal, check the backtrace. - - gdb_test "signal SIGUSR1" "Breakpoint.*handler.*" - gdb_test "bt" \ - "#0 handler .*#1 .signal handler called.*#2 func1 .*\#3 .*main.*" \ - "backtrace for SIGUSR1" - - # The problem here is that the breakpoint at func1 will be - # inserted, and when the system finishes with the signal - # handler it will try to execute there. For GDB to try to - # remember that it was going to step over a breakpoint when a - # signal happened, distinguish this case from the case where - # func1 is called from the signal handler, etc., seems - # exceedingly difficult. So don't expect this to get fixed - # anytime soon. - - setup_xfail "*-*-*" - set test "continue to func2" - gdb_test_multiple "continue" "$test" { - -re "Breakpoint.*func2.*$gdb_prompt $" { - pass "$test" - } - -re "Breakpoint.*func1.*$gdb_prompt $" { - fail "$test" - gdb_test "continue" "Breakpoint.*func2.*" \ - "extra continue to func2" - } - } - - # In running to func2, the 2rd alarm call will have been set - # up, let it be delivered. - - # This doesn't work correctly on platforms with hardware single - # step... - - sleep 2 - - setup_kfail "i*86-*-*" gdb/1738 - setup_kfail "x86_64-*-*" gdb/1738 - setup_kfail "rs6000-*-*" gdb/1738 - setup_kfail "powerpc-*-*" gdb/1738 - setup_kfail "sparc-*-*" gdb/1738 - gdb_test "continue" "Breakpoint.*handler.*" \ - "continue to handler for 3rd alarm call" - - setup_kfail "i*86-*-*" gdb/1738 - setup_kfail "x86_64-*-*" gdb/1738 - setup_kfail "rs6000-*-*" gdb/1738 - setup_kfail "powerpc-*-*" gdb/1738 - setup_kfail "sparc-*-*" gdb/1738 - gdb_test "backtrace" \ - "#0 handler.*#1.*signal handler called.*#2 func2.*#3.*main.*" \ - "backtrace for 3rd alarm" - - # If we succeeded a continue will return from the handler to - # func2. GDB now has `forgotten' that it intended to step - # over the breakpoint at func2 and will stop at func2. - - setup_xfail "*-*-*" - set test "continue to program exit" - gdb_test_multiple "continue" "$test" { - -re "Program exited with code 010\\." { - pass "$test" - } - -re "Breakpoint.*func2.*$gdb_prompt $" { - fail "$test" - gdb_test "continue" "Program exited with code 010\\." \ - "extra continue to program exit" - } - } - } -} - gdb_exit gdb_start @@ -185,7 +75,6 @@ gdb_exit gdb_start gdb_reinitialize_dir $srcdir/$subdir gdb_load $binfile -signal_tests_1 if [runto_main] then { @@ -378,10 +267,10 @@ The program being debugged stopped while # the inferior. (This probably causes the inferior to run away. # Be prepared to rerun to main for further testing.) - gdb_test "signal 5" \ - "Continuing with signal SIGTRAP.*" \ - "sent signal 5" - + gdb_test "signal SIGUSR1" "Breakpoint.*handler.*" + gdb_test "bt" \ + "#0 handler .*#1 .signal handler called.*\#2 .*main.*" \ + "backtrace for SIGUSR1" } return 0 --------------080502030805020708050603-- --------------020108070607000306050203--