From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 852 invoked by alias); 6 Mar 2007 01:30:47 -0000 Received: (qmail 844 invoked by uid 22791); 6 Mar 2007 01:30:47 -0000 X-Spam-Check-By: sourceware.org Received: from sccrmhc13.comcast.net (HELO sccrmhc13.comcast.net) (63.240.77.83) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Mar 2007 01:30:45 +0000 Received: from [172.22.0.103] (c-71-63-50-10.hsd1.va.comcast.net[71.63.50.10]) by comcast.net (sccrmhc13) with ESMTP id <2007030601303801300135f3e>; Tue, 6 Mar 2007 01:30:43 +0000 Message-ID: <45ECC43E.7090801@ringle.org> Date: Tue, 06 Mar 2007 01:30:00 -0000 From: Jon Ringle User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Michael Snyder CC: gdb@sourceware.org Subject: Re: gdbserver signals interfere with {next,step{,i}} References: <45EC780E.60705@ringle.org> <1173125584.29183.20.camel@localhost.localdomain> In-Reply-To: <1173125584.29183.20.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00072.txt.bz2 Michael Snyder wrote: > 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. > > > I just tried the test case I posted to the list with SIGUSR2 instead with the same results. Jon