From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15795 invoked by alias); 29 Sep 2006 18:10:09 -0000 Received: (qmail 15786 invoked by uid 22791); 29 Sep 2006 18:10:08 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.palmsource.com (HELO mx2.palmsource.com) (12.7.175.14) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 29 Sep 2006 18:10:00 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id 1CFB026CA1; Fri, 29 Sep 2006 11:09:59 -0700 (PDT) Received: from mx2.palmsource.com ([127.0.0.1]) by localhost (mx2.palmsource.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25422-01-13; Fri, 29 Sep 2006 11:09:58 -0700 (PDT) Received: from ussunex01.palmsource.com (unknown [192.168.101.9]) by mx2.palmsource.com (Postfix) with ESMTP id 4145E26C90; Fri, 29 Sep 2006 11:09:58 -0700 (PDT) Received: from 192.168.92.59 ([192.168.92.59]) by ussunex01.palmsource.com ([192.168.101.9]) via Exchange Front-End Server owa.palmsource.com ([10.0.20.17]) with Microsoft Exchange Server HTTP-DAV ; Fri, 29 Sep 2006 18:09:58 +0000 Received: from svmsnyderlnx by owa.palmsource.com; 29 Sep 2006 11:09:57 -0700 Subject: Re: gdb for multicore processors? From: Michael Snyder To: Bridge Wu Cc: gdb@sources.redhat.com In-Reply-To: <246188420609282029u672a8ff7nc836c2cda35cf95@mail.gmail.com> References: <246188420609282029u672a8ff7nc836c2cda35cf95@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 29 Sep 2006 18:10:00 -0000 Message-Id: <1159553397.9768.259.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00189.txt.bz2 On Fri, 2006-09-29 at 11:29 +0800, Bridge Wu wrote: > Hello, > > I want to know whether gdb support multicore debugging now. I searched > below from this mailing list, but didn't know the current status. Is > there any plan or roadmap to support multicore debugging? The most interesting "thread" of conversation (pun intended) that I've taken part in has been with the idea that, if they are symmetric multi-processors and if they are running the same code, we could somehow hoax them into the thread model. Treat each core as a thread. This could for instance be done with cooperation from the target side. If gdb were talking to a remote stub or gdbserver, then the remote side could simply report each core using a different "thread id", and to gdb it would be transparent.