From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30164 invoked by alias); 31 May 2007 17:23:59 -0000 Received: (qmail 30156 invoked by uid 22791); 31 May 2007 17:23:58 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 31 May 2007 17:23:57 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 8D011982DF for ; Thu, 31 May 2007 17:23:55 +0000 (GMT) Received: from localhost.localdomain (nc-71-2-221-6.dyn.embarqhsd.net [71.2.221.6]) by nan.false.org (Postfix) with ESMTP id 46808982DD for ; Thu, 31 May 2007 17:23:55 +0000 (GMT) Received: by localhost.localdomain (Postfix, from userid 1000) id 6294217762E; Thu, 31 May 2007 13:23:55 -0400 (EDT) Resent-From: drow@false.org Resent-Date: Thu, 31 May 2007 13:23:55 -0400 Resent-Message-ID: <20070531172355.GK23651@localhost.localdomain> Resent-To: gdb@sourceware.org Date: Thu, 31 May 2007 17:23:00 -0000 From: Daniel Jacobowitz To: Michael Zhang Cc: gdb@sourceware.org Subject: Re: remotely debugging muti-threaded applicaton did not work with gdb 6.3.50.20050725-cvs Message-ID: <20070529181814.GA546@localhost.localdomain> Mail-Followup-To: Michael Zhang , gdb@sourceware.org References: <3d234af30705290913u3d57fa8fp4ab53400027658a0@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3d234af30705290913u3d57fa8fp4ab53400027658a0@mail.gmail.com> 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-05/txt/msg00183.txt.bz2 On Tue, May 29, 2007 at 10:13:57AM -0600, Michael Zhang wrote: > Debugging problem: > > The gdb on the host can talk to the gdbserver on the target and I did > not forget to set "solib-absolute-prefix". If I set breakpoints before > the multiple threads are spawned, I could step through the code when > the breakpoint was hit. However, once the application finished > creating threads and if I stop the program to step through, it won't > step and alway stuck in libc.so.6. The worst is all the threads are > getting killed. And "info threads" never returns anything just > reporting that the gdbserver could not get thread list. If you do not have any luck with David's suggestions, please send a more specific problem report afterwards. I need to see at least an exact transcript of your session to guess what is wrong. -- Daniel Jacobowitz CodeSourcery