From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22674 invoked by alias); 2 Mar 2007 15:04:44 -0000 Received: (qmail 22603 invoked from network); 2 Mar 2007 15:04:21 -0000 Received: from unknown (72.22.69.69) by sourceware.org with QMTP; 2 Mar 2007 15:04:21 -0000 Received: (qmail 27428 invoked by uid 3521); 2 Mar 2007 15:03:30 -0000 Received: from 220.225.33.101 by rs384.securehostserver.com (envelope-from , uid 1002) with qmail-scanner-1.25st (clamdscan: 0.88/1245. spamassassin: 3.1.0. perlscan: 1.25st. Clear:RC:1(220.225.33.101):. Processed in 0.523189 secs); 02 Mar 2007 15:03:30 -0000 Received: from unknown (HELO ?192.168.100.106?) (220.225.33.101) by rs384.securehostserver.com with SMTP; 2 Mar 2007 15:03:29 -0000 Subject: Re: Improving GDB for multicore and embedded system! From: Ramana Radhakrishnan Reply-To: ramana.radhakrishnan@celunite.com To: Daniel Jacobowitz , "Dominique Toupin (QA/EMC)" Cc: Denis PILAT , gdb@sourceware.org In-Reply-To: <20070302135424.GA30113@caradoc.them.org> References: <67048CBE51B1644D89DDD3B7C9F2D19E032884F7@ecamlmw720.eamcs.ericsson.se> <45E7E9A7.5050705@st.com> <20070302135424.GA30113@caradoc.them.org> Content-Type: text/plain Date: Fri, 02 Mar 2007 15:04:00 -0000 Message-Id: <1172847786.2170.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 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/msg00037.txt.bz2 Hi, On Fri, 2007-03-02 at 08:54 -0500, Daniel Jacobowitz wrote: > On Fri, Mar 02, 2007 at 10:08:55AM +0100, Denis PILAT wrote: > > Today multicore debugging means multiple instance of gdb running at the > > same time. I don't know how possible it is to enhance gdb so that it can > > handle multiple programs running on different architecture. > > I guess Daniel should have a good vision on that. > > No one has ever convinced me that there's a good reason to do this, > rather than wire up things like DSF to drive multiple GDB's, if the > cores are not all running the same architecture and program image. If > they are, we generally present them as threads, and that works very > well. > > However, I have relatively little experience with non-symmetric > multicore debugging - I have a board lab at home but it doesn't > include any multicore targets, and we haven't done much with them at > my job, either. I'm always interested in learning more about new > debugging models, or having an opportunity to do work on them. In an earlier incarnation, we played with getting debug working across 2 different targets ( gosh! nearly 4 years ago now) - debugging a native x86 Linux application and the ARM Linux kernel over kgdb within the same session. It worked ok for a prototype but then we could never get around to doing more with it because of resource constraints and the lack of a genuine debug use case on such a target. Getting this demo'd on a board was a problem due to the lack of open gdb ports / JTAG interfaces for some DSP's that were available with such SOC's then . Another problem is the programming model on multi-cores , it varies between platforms quite a bit - you could have a statically linked executable with all the object files for the different cores on it built in together - or you can have Linux apps running on something like an ARM and a DSP application loaded separately. As you once put it in an earlier thread - getting the UI aspects right from the CLI as well from MI are among the biggest challenges. We've had some other discussions on this list sometime in 2005. http://sourceware.org/ml/gdb/2005-09/msg00180.html Don't know if you have seen them - There is always hope that sometime someday we'll be able to do something about this . I'll watch out for that - My 10 paise. HTH. -- cheers Ramana Ramana Radhakrishnan GNU Tools Celunite Inc (www.celunite.com) Open Mobile Linux Platforms