From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17996 invoked by alias); 28 Sep 2005 11:13:29 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 17952 invoked by uid 22791); 28 Sep 2005 11:13:14 -0000 Received: from [220.225.32.98] (HELO calvin.codito.co.in) (220.225.32.98) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 28 Sep 2005 11:13:14 +0000 Received: from zirakzigil.codito.co.in (zirakzigil.codito.co.in [192.168.100.106]) by calvin.codito.co.in (8.13.2/8.13.2/Debian-1) with ESMTP id j8SBBQiX025376; Wed, 28 Sep 2005 16:41:27 +0530 Subject: Re: Is multiprocessor debugging multithreaded debugging? From: Ramana Radhakrishnan Reply-To: ramana.radhakrishnan@codito.com To: Steven Johnson Cc: Anupama Chandwani , drow@false.org, gdb@sources.redhat.com In-Reply-To: <433A6D8B.8080605@sakuraindustries.com> References: <689eb347050928020544f90509@mail.gmail.com> <433A6D8B.8080605@sakuraindustries.com> Content-Type: text/plain Date: Wed, 28 Sep 2005 11:13:00 -0000 Message-Id: <1127905917.5974.36.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-09/txt/msg00229.txt.bz2 Hi , As much as I agree with you there might be other use cases that are not possible with the setup you describe. One example is to be able to be able to single step 2 processors and let a 3rd continue merrily or single step in lockstep a group of processors. Providing relational breakpoints between multiple processors might be another nifty feature. Lets say something like b if val_in_pgm_in_proc2 is 0xcafebabe. My 2 bits on the topic. cheers Ramana On Wed, 2005-09-28 at 21:16 +1100, Steven Johnson wrote: > Anupama Chandwani wrote: > > >In continuation with my prev mail.. > >I want to extend gdb to debug homing ogenous multiprocessor system > > > > > >(say multiple ARM or x86 processors on single chip) by remote > >debugging in a single session of gdb. > > > >What i want to know is are there enough applications being written on > >such multi processors? Also are there different executables being > >required to be debugged simultaneously? Coz this is what i want to > >extend in further.. Each processor running a different executable so > >the processors dont share memory & run with different images of code. > > > > > This is commonly called "Asynchronous" Multi Processing. > > >An application of such debugger could be while building an OS but that > >wouldnt involve different executables.. So are there applications > >requiring to run different executables on each processor? Say for > >example a prog gives a certain bug on when there is certain other > >program running on the other processor or something similar to > >this.... > > > > > Yes in the embedded world, there are many examples of Asynchronous Multi > Processor designs. They are by far the easiest multi processor design > to implement. I for example have worked on a board that had 3 MSP430's, > each had a unique function, and they intercommunicated over a custom > parallel bus to coordinate their activities. Worked sweet, had high > performance, and was really cheap. > > >As far as i know this done by multiplexing the JTAG interface (for > >x86) &different sessions of gdb right now. Any other? And any flaws or > >inconvenience with present methods? > > > > > This is exactly how it is done, multiple sessions of GDB. This, in my > opinion is the right way to go. Not all Asynchronous multi processor > designs have homogeneous pprocessors (ie, you may have an MPC860 > handling comms, and a MIPS Chip doing some number crunching. 1 is a > power PC, the other is a MIPS. Both have different debug interfaces. > > Now if you had a system say, where you had 3 MIPS Chips, hooked up on > the same EJTAG interface, you would need to handle that with some nifty > EJTAG code in your (pseudo) stub to ensure each device was uniquely > addressed and they didnt interfere with one another, so that you could > start up 3 GDB sessions to debug your 3 processors, but then it becomes > a problem for the stub. > > What im saying is I dont think a single instance of GDB needs to be > complicated to try and debug multiple "tasks" simultaneously. I dont > have any problems with running GDB as many times as I want. For example > with the MSP430 example, I had (at various times) GDB running 5 times on > the one PC. One was debugging a local PC app that talked to my MSP430 > board. 3 were talking to the MSP430 board, the last was talking to yet > another device (that had an MPC862 as its processor), I just ran each in > a separate "Desktop" under KDE and then switched to the one i had to > deal with at the time. No problems, worked easily. > > Hope that gives you insight into one application of what you discussed. > Steven -- Ramana Radhakrishnan GNU Tools codito ergo sum (www.codito.com)