From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29874 invoked by alias); 6 Mar 2007 14:39:44 -0000 Received: (qmail 29866 invoked by uid 22791); 6 Mar 2007 14:39:44 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 06 Mar 2007 14:39:33 +0000 Received: from dsl093-172-095.pit1.dsl.speakeasy.net ([66.93.172.95] helo=caradoc.them.org) by nevyn.them.org with esmtp (Exim 4.63) (envelope-from ) id 1HOap7-0004BR-AJ; Tue, 06 Mar 2007 09:39:29 -0500 Received: from drow by caradoc.them.org with local (Exim 4.63) (envelope-from ) id 1HOap6-0007m8-Md; Tue, 06 Mar 2007 09:39:28 -0500 Date: Tue, 06 Mar 2007 14:39:00 -0000 From: Daniel Jacobowitz To: Jon Ringle Cc: Michael Snyder , gdb@sourceware.org Subject: Re: [SPAM] Re: gdbserver signals interfere with {next,step{,i}} Message-ID: <20070306143928.GA29866@caradoc.them.org> Mail-Followup-To: Jon Ringle , Michael Snyder , gdb@sourceware.org References: <45EC780E.60705@ringle.org> <20070305201726.GA11385@caradoc.them.org> <45ECA592.5080802@ringle.org> <1173145366.29183.56.camel@localhost.localdomain> <45ECC84A.9020702@ringle.org> <1173147085.29183.61.camel@localhost.localdomain> <45ECD0DE.206@ringle.org> <20070306122541.GA1414@caradoc.them.org> <45ED7B32.5060100@ringle.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45ED7B32.5060100@ringle.org> User-Agent: Mutt/1.5.13 (2006-08-11) 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/msg00083.txt.bz2 On Tue, Mar 06, 2007 at 09:31:14AM -0500, Jon Ringle wrote: > Daniel Jacobowitz wrote: > >On Mon, Mar 05, 2007 at 09:24:30PM -0500, Jon Ringle wrote: > > > >>My target uses uclibc-0.9.28 rather than a glibc libc. Could that be a > >>factor here? > >> > > > >Yes, it certainly could be. > > > > > When I use a native gdb-6.6 on the uclibc target, I don't see any > SIGUSR1 signals being intercepted by gdb (so I don't have to do 'handle > SIGUSR1 nostop noprint') and I see correct behaviour using 'next'. What > would gdbserver-6.6 be doing different that a native gdb-6.6 in regards > to signal handling? It may have decided that they are used by uClibc's threading library. Beyond here I do not think I can make any useful guesses; all the logic is different between gdb and gdbserver. You'd have to debug it. If it's decided threading uses them, "handle SIGUSR1" should show nostop noprint alreayd. Otherwise, it may just never be notified of the signal - that would be a bug somewhere. -- Daniel Jacobowitz CodeSourcery