From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11878 invoked by alias); 9 Aug 2011 14:32:48 -0000 Received: (qmail 11866 invoked by uid 22791); 9 Aug 2011 14:32:47 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 09 Aug 2011 14:32:33 +0000 Received: (qmail 32519 invoked from network); 9 Aug 2011 14:32:32 -0000 Received: from unknown (HELO ?192.168.0.101?) (yao@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 Aug 2011 14:32:32 -0000 Message-ID: <4E414503.7080201@codesourcery.com> Date: Tue, 09 Aug 2011 14:32:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mark Kettenis CC: pedro@codesourcery.com, gdb-patches@sourceware.org Subject: Re: [patch] Skip kill-after-signal.exp if hw single-step is not supported References: <4E259815.8080001@codesourcery.com> <201107201605.43767.pedro@codesourcery.com> <201107232247.p6NMlwVx029216@glazunov.sibelius.xs4all.nl> In-Reply-To: <201107232247.p6NMlwVx029216@glazunov.sibelius.xs4all.nl> Content-Type: multipart/mixed; boundary="------------030602070107050707060408" X-IsSubscribed: yes 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 X-SW-Source: 2011-08/txt/msg00181.txt.bz2 This is a multi-part message in MIME format. --------------030602070107050707060408 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-length: 1083 On 07/24/2011 06:47 AM, Mark Kettenis wrote: >> From: Pedro Alves >> Date: Wed, 20 Jul 2011 16:05:43 +0100 >> >> Other archs !x86, and other kernels/stubs/servers !Linux that >> can do hardware stepping. If we're going to have a list, invert >> the logic of the check, defaulting to running the test, and leaving >> out archs were we know software stepping is used. Some targets, >> like x86/OpenBSD and MacOS, although can hardware step, can't step >> into a handler. > > Just FYI, it's putting breakpoints into the signal trampoline that is > the issue, at least on OpenBSD. Single-stepping should work fine on > OpenBSD/i386 and OpenBSD/amd64 and all other architectures where it's > done in hardware. This is the 2nd version of the patch. A new predicate, single_step_to_signal_handler_p, is added in lib/gdb.exp. In default, it returns true, and return false on target "arm*-*-* and "mips*-*-*". I don't find any other tests using "stepi" to step into signal handler, so I only changed kill-after-signal.exp. OK for mainline? -- Yao (齐尧) --------------030602070107050707060408 Content-Type: text/x-patch; name="single_step_to_signal_handler_p.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="single_step_to_signal_handler_p.patch" Content-length: 1627 gdb/testsuite/ * lib/gdb.exp (single_step_to_signal_handler_p): New. * gdb.base/kill-after-signal.exp: Skip if target supports single step to signal handler. diff --git a/gdb/testsuite/gdb.base/kill-after-signal.exp b/gdb/testsuite/gdb.base/kill-after-signal.exp index eecad2e..f7086fc 100644 --- a/gdb/testsuite/gdb.base/kill-after-signal.exp +++ b/gdb/testsuite/gdb.base/kill-after-signal.exp @@ -14,6 +14,12 @@ # along with this program. If not, see . set testfile "kill-after-signal" + +if { ![single_step_to_signal_handler_p] } { + untested ${testfile}.exp + return +} + if [prepare_for_testing ${testfile}.exp ${testfile}] { return -1 } diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index ef5ad5c..b967a97 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -1527,6 +1527,21 @@ proc support_complex_tests {} { return $support_complex_tests_saved } +# Return 1 if target hardware or OS supports single stepping to single handler, +# otherwise, return 0. + +proc single_step_to_signal_handler_p {} { + + # Targets don't have hardware single step. On these targets, when a signal + # is delivered during software single step, gdb is unable to determine the + # next instruction addresses, because start of signal handler is one of them. + if { [istarget "arm*-*-*"] || [istarget "mips*-*-*"] } { + return 0 + } + + return 1 +} + # Return 1 if target is ILP32. # This cannot be decided simply from looking at the target string, # as it might depend on externally passed compiler options like -m64. --------------030602070107050707060408--