From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32472 invoked by alias); 6 Mar 2007 20:18:55 -0000 Received: (qmail 32463 invoked by uid 22791); 6 Mar 2007 20:18:54 -0000 X-Spam-Check-By: sourceware.org Received: from sccrmhc11.comcast.net (HELO sccrmhc11.comcast.net) (204.127.200.81) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Mar 2007 20:18:45 +0000 Received: from [172.22.0.103] (c-71-63-50-10.hsd1.va.comcast.net[71.63.50.10]) by comcast.net (sccrmhc11) with ESMTP id <2007030620184301100d7a8qe>; Tue, 6 Mar 2007 20:18:43 +0000 Message-ID: <45EDCCA0.1020307@ringle.org> Date: Tue, 06 Mar 2007 20:18: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, Daniel Jacobowitz 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> <1173210371.29183.101.camel@localhost.localdomain> In-Reply-To: <1173210371.29183.101.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/msg00105.txt.bz2 Michael Snyder wrote: > On Tue, 2007-03-06 at 09:31 -0500, Jon Ringle wrote: > >> 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'. >> The above comment about SIGUSR1 is incorrect. When I ran the test, I was actually using SIGALRM which is why I didn't see any SIGUSR1 events... sorry for the confusion there. > > Important question -- does gdb thread support (either native or > remote/gdbserver) work at all with uclibc? Yes, thread support seems to work just fine from both native gdb and gdbserver <-> crossgdb scenarios. "info threads" shows me a list of threads and I can use the "thread" command to switch thread contexts and see a backtrace of each thread. Jon