From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9484 invoked by alias); 7 Nov 2007 02:32:10 -0000 Received: (qmail 9473 invoked by uid 22791); 7 Nov 2007 02:32:09 -0000 X-Spam-Check-By: sourceware.org Received: from nf-out-0910.google.com (HELO nf-out-0910.google.com) (64.233.182.188) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 07 Nov 2007 02:32:07 +0000 Received: by nf-out-0910.google.com with SMTP id b11so1747310nfh for ; Tue, 06 Nov 2007 18:32:04 -0800 (PST) Received: by 10.78.172.20 with SMTP id u20mr5541475hue.1194402724320; Tue, 06 Nov 2007 18:32:04 -0800 (PST) Received: by 10.78.83.18 with HTTP; Tue, 6 Nov 2007 18:32:04 -0800 (PST) Message-ID: Date: Wed, 07 Nov 2007 02:32:00 -0000 From: "Siva Velusamy" To: gdb@sourceware.org Subject: Ctrl+C when a watchpoint is set gdb MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-11/txt/msg00041.txt.bz2 Hello, I'm trying to debug the following strange gdb behavior on an embedded target: (gdb) watch foo (gdb) c (gdb) Hardware watchpoint 2: foo Old value = 0 New value = 10 call_func (a=) at bar.c:4 4 } (gdb) c Continuing. <--------------------- At this point Ctrl+C does not stop gdb. What happens is that when a Ctrl+C is pressed, gdb receives control, goes into infrun.c and checks if the processor has stopped due to an existing breakpoint. (The only existing breakpoint is a watchpoint on foo.) However, the function bpstat_explains_signal is defined as follows: breakpoint.h:547 /* Nonzero if a signal that we got in wait() was due to circumstances explained by the BS. */ /* Currently that is true if we have hit a breakpoint, or if there is a watchpoint enabled. */ #define bpstat_explains_signal(bs) ((bs) != NULL) Since there is a watchpoint defined, this ends up evaluating to true, even though this is a trap signal caused by Ctrl+C. Eventually, this leads to keep_going(ecs) being called. In cases where a watchpoint is not defined, then ecs->random_signal ends up being 1, and gdb gives control back to the user. This happens for two cpu targets: powerpc 405 and MicroBlaze. Could someone point me in the right direction as to what exactly to look for? The PowerPC target is pretty much unmodified gdb-6.5, so I'm surprised that doesn't work. Thanks! -- In the end, everything is a gag. Charlie Chaplin