From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20919 invoked by alias); 6 Mar 2007 01:17:56 -0000 Received: (qmail 20910 invoked by uid 22791); 6 Mar 2007 01:17:55 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.palmsource.com (HELO mx2.palmsource.com) (12.7.175.14) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Mar 2007 01:17:54 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id 7E9CC137ABE; Mon, 5 Mar 2007 15:57:27 -0800 (PST) Received: from mx2.palmsource.com ([127.0.0.1]) by localhost (mx2.palmsource.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07228-03-4; Mon, 5 Mar 2007 15:57:26 -0800 (PST) Received: from ussunex01.palmsource.com (unknown [192.168.101.9]) by mx2.palmsource.com (Postfix) with ESMTP id D138A1366CD; Mon, 5 Mar 2007 12:13:05 -0800 (PST) Received: from 192.168.92.81 ([192.168.92.81]) by ussunex01.palmsource.com ([192.168.101.9]) via Exchange Front-End Server owa.palmsource.com ([10.0.20.17]) with Microsoft Exchange Server HTTP-DAV ; Mon, 5 Mar 2007 20:13:05 +0000 Received: from svmsnyderlnx by owa.palmsource.com; 05 Mar 2007 12:13:04 -0800 Subject: Re: gdbserver signals interfere with {next,step{,i}} From: Michael Snyder To: Jon Ringle Cc: gdb@sourceware.org In-Reply-To: <45EC780E.60705@ringle.org> References: <45EC780E.60705@ringle.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 06 Mar 2007 01:17:00 -0000 Message-Id: <1173125584.29183.20.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 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-03/txt/msg00071.txt.bz2 On Mon, 2007-03-05 at 15:05 -0500, Jon Ringle wrote: > Hello, > > I have an application that uses SIGUSR1 to receive timer interrupts. > I've done 'handle SIGUSR1 nostop noprint' to avoid gdb from stopping on > SIGUSR1. > I've found that when debugging this application using gdbserver, that I > can't use next, nexti, step, or stepi. When I use one of these commands, > the application usually just continues without stopping at the next > line/instruction. > > If I use a native gdb on the target the problem does not occur. > If I disable my app from generating the SIGUSR1 and use gdbserver, the > problem also goes away. > > I am using gdb-6.6 for gdbserver, native gdb and cross gdb. Is it possible for your app to use a different signal? SIGUSR1 has been used by glibc in the old linux pthreads implementation, and gdb (and gdbserver) both have special handling built into them for that signal.