From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6454 invoked by alias); 15 May 2011 12:52:41 -0000 Received: (qmail 6446 invoked by uid 22791); 15 May 2011 12:52:41 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 15 May 2011 12:52:23 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p4FCqNC6031392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 15 May 2011 08:52:23 -0400 Received: from host1.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p4FCqKiF012762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 15 May 2011 08:52:22 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p4FCqKS7010470; Sun, 15 May 2011 14:52:20 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p4FCqHqV010460; Sun, 15 May 2011 14:52:17 +0200 Date: Sun, 15 May 2011 12:52:00 -0000 From: Jan Kratochvil To: Shrikanth Kamath Cc: gdb@sourceware.org Subject: Re: Non-intrusive remote GDB Message-ID: <20110515125217.GA10100@host1.jankratochvil.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2011-05/txt/msg00066.txt.bz2 On Wed, 11 May 2011 19:40:39 +0200, Shrikanth Kamath wrote: > My question is it possible / feasible to attempt the remote GDB attach > only to single micro kernel thread in the PPC plane > and not halt it totally? Say the other threads proceed as normal. During the initial attach normally all the threads get attached and they get stopped by the attachment. Later you can have stopped only one specific thread by using non-stop mode: $ info '(gdb)Non-Stop Mode' To not to stop the other threads at all one needs to disallow finding gdbserver the file libthread_db.so.1, besides reconfiguring GDB as a safe bet you can rename/hide it on the PPC board. `info threads' shows only the single/initial thread. (Assuming GNU/Linux environment on the PPC borad; you did not say.) Regards, Jan