From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8144 invoked by alias); 9 Aug 2004 16:17:16 -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 8118 invoked from network); 9 Aug 2004 16:17:12 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 9 Aug 2004 16:17:12 -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 i79GHCe3013531 for ; Mon, 9 Aug 2004 12:17:12 -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 i79GGwa05798; Mon, 9 Aug 2004 12:16:59 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id AC4B62B9D; Mon, 9 Aug 2004 12:16:47 -0400 (EDT) Message-ID: <4117A36F.6050603@gnu.org> Date: Mon, 09 Aug 2004 16:17:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040801 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: mec.gnu@mindspring.com, Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: [testsuite] Kfail signals.exp failures References: <20040808231810.GA24826@nevyn.them.org> <200408090745.i797jnFc000594@elgar.kettenis.dyndns.org> <20040809131105.GA27539@nevyn.them.org> <41178316.7000906@gnu.org> <20040809151800.GA3986@nevyn.them.org> In-Reply-To: <20040809151800.GA3986@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00313.txt.bz2 > Yes, sigbpt.exp passes. > > breakpoints/1702 is about the tendency of ia32 hardware to step two > instructions over int $0x80. That does not affect this test case; see > the analysis in gdb/1738. 1702 is about broken kernels. Both the s390 and PPC in question have a fixed kernel. Since sigbpt.exp passes it soulds like your kernel is fixed? > Please explain why the KFAILs are not correct, or why a new test is > needed. This is a bug in GDB; I analyzed the bug, filed a bug report, > and marked the test which fails because of this bug as KFAILed to the > PR. Judging from the historical use of XFAIL, this is the precise bug > that the test was written for. Here's the original comment that went with the XFAILs: # GDB yanks out the breakpoints to step over the breakpoint it # stopped at, which means the breakpoint at handler is yanked. # But if SOFTWARE_SINGLE_STEP_P, we won't get another chance to # reinsert them (at least not with procfs, where we tell the kernel # not to tell gdb about `pass' signals). So the fix would appear to # be to just yank that one breakpoint when we step over it. and here's the new comment: # This doesn't work correctly on platforms with hardware single # step... The test does pass on systems with working h/w single-step. Can we fix the comment? > My analysis does not explain why it passes on S/390, or on PPC. If you > want to, then remove the PPC kfail. More anaysis and tests are needed here: - something to cover "next" (next is different to continue) - something to explain why i386 (what other systems did you test this on?) fails the continue (decr pc after break?) can we do that? Andrew