From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23503 invoked by alias); 20 Jul 2010 13:29:14 -0000 Received: (qmail 23490 invoked by uid 22791); 20 Jul 2010 13:29:13 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_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, 20 Jul 2010 13:29:02 +0000 Received: (qmail 19321 invoked from network); 20 Jul 2010 13:29:01 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 20 Jul 2010 13:29:01 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [patch] Fix linux-ia64 on SIGILL for deleted breakpoint Date: Tue, 20 Jul 2010 13:29:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.31-11-rt; KDE/4.4.2; x86_64; ; ) Cc: Jan Kratochvil References: <20100719085817.GA24395@host1.dyn.jankratochvil.net> In-Reply-To: <20100719085817.GA24395@host1.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007201428.59184.pedro@codesourcery.com> 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: 2010-07/txt/msg00299.txt.bz2 On Monday 19 July 2010 09:58:17, Jan Kratochvil wrote: > Hi, > > in some cases ia64 can generate SIGILL instead of SIGTRAP. Guessing it is > a CPU bug instead of Linux kernel bug (but I may be wrong). > https://bugzilla.redhat.com/show_bug.cgi?id=615538 > http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/ia64-sigill.c?cvsroot=systemtap > > Anyway FSF GDB already contains code for handling such cases (and not only > SIGILL). Just the time it gets executed the breakpoint which generated the > signal may be already deleted and GDB stops with: > Program received signal SIGILL, Illegal instruction. > > I do not think it can be solved fully target-independent. linux-nat.c already > does some postponing of signals using > kill_lwp (GET_LWP (lp->ptid), WSTOPSIG (lp->status)); > and the moment linux-nat.c will read back such postponed signal its breakpoint > may be already deleted (and thus it will never get to target-independent parts > of GDB such as infrun.c). That's a general problem with "real" SIGTRAP breakpoints as well. linux-nat.c handles this by "cancelling" the breakpoint, so that it is hit again later on resume. "cancelling" just means something like: Since we're not reporting the event to the user right now, just ignore it. If the breakpoint is still inserted later, the next time we ask the target for an event (on resume), the inferior will trap on the same breakpoint again; we'll report it then, if so. I don't see why this can't be extended to handle SIGILL breakpoints too (with the difference that there's no PC adjustment required, you just discard the signal). Simply swapping SIGILL for SIGTRAP without accounting for the PC adjustment that GDB will try to do on the SIGTRAP (thinking it was a real SIGTRAP) makes me a bit nervous. -- Pedro Alves