From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-28006-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 10288 invoked by alias); 6 Mar 2007 14:57:32 -0000
Received: (qmail 10279 invoked by uid 22791); 6 Mar 2007 14:57:32 -0000
X-Spam-Check-By: sourceware.org
Received: from rwcrmhc12.comcast.net (HELO rwcrmhc12.comcast.net) (204.127.192.82)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Mar 2007 14:57:20 +0000
Received: from [172.22.0.103] (c-71-63-50-10.hsd1.va.comcast.net[71.63.50.10])           by comcast.net (rwcrmhc12) with ESMTP           id <20070306145718m1200iki2ce>; Tue, 6 Mar 2007 14:57:18 +0000
Message-ID: <45ED814D.1040409@ringle.org>
Date: Tue, 06 Mar 2007 14:57:00 -0000
From: Jon Ringle <jon@ringle.org>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Jon Ringle <jon@ringle.org>,   Michael Snyder <Michael.Snyder@palmsource.com>,   gdb@sourceware.org
Subject: Re: [SPAM]  Re: gdbserver signals interfere with {next,step{,i}}
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> <20070306143928.GA29866@caradoc.them.org>
In-Reply-To: <20070306143928.GA29866@caradoc.them.org>
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: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2007-03/txt/msg00084.txt.bz2

Daniel Jacobowitz wrote:
> 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.
>
>   
Sorry, my bad here. I had been playing around with using different 
signals last night and left the code using SIGALRM instead, which 
defaults to nostop noprint. When I switched back to using SIGUSR1 again, 
I had to use 'handle SIGUSR1 nostop noprint' on the native gdb.

Jon