From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7170 invoked by alias); 16 Jun 2008 00:20:19 -0000 Received: (qmail 7162 invoked by uid 22791); 16 Jun 2008 00:20:18 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 16 Jun 2008 00:20:01 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id BA4D83BD14; Sun, 15 Jun 2008 17:19:59 -0700 (PDT) Subject: Re: What does gdb stub need for thread aware debugging on embedded system? From: Michael Snyder To: John Carter Cc: gdb@sourceware.org In-Reply-To: References: Content-Type: text/plain Date: Mon, 16 Jun 2008 00:20:00 -0000 Message-Id: <1213575599.3601.898.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit 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: 2008-06/txt/msg00154.txt.bz2 On Mon, 2008-06-16 at 12:09 +1200, John Carter wrote: > I'm looking to get thread aware debugging running on our "sparc-alike" > Leon II processor. > > Unlike the usual sparc stub, I cannot get thread information from > Solaris as we're not running solaris on this device. > > If I understand things correctly, getting gdb working should just be a > matter of tying gdb/sparc-stub.c to our serial ports by defining > extern void putDebugChar(); /* write a single character */ > extern int getDebugChar(); /* read and return a single char */ > > Grepping through that code the word "thread" doesn't occur. > > What I'm missing is how does gdb get information about threads from > the devices OS to gdb running on the desktop. > > Any pointers to the right bit of documentation / code would be most > welcome. At the time that that code was written, threads were very far from the minds of people who wrote remote gdb stubs! Look at gdbserver -- it has support for threads.