From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23127 invoked by alias); 28 Sep 2005 10:17:00 -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 23003 invoked from network); 28 Sep 2005 10:16:33 -0000 Received: from unknown (202.80.33.51) by sourceware.org with QMTP; 28 Sep 2005 10:16:33 -0000 Received: (qmail 10347 invoked from network); 28 Sep 2005 10:16:28 -0000 X-Anti-Virus: Message scanned for viruses by TVL Received: from unknown (HELO [192.168.2.15]) ([202.80.36.18]) (envelope-sender ) by mail.vanuatu.com.vu (qmail-ldap-1.03) with SMTP for ; 28 Sep 2005 10:16:28 -0000 Message-ID: <433A6D8B.8080605@sakuraindustries.com> Date: Wed, 28 Sep 2005 10:17:00 -0000 From: Steven Johnson User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) MIME-Version: 1.0 To: Anupama Chandwani CC: drow@false.org, gdb@sources.redhat.com Subject: Re: Is multiprocessor debugging multithreaded debugging? References: <689eb347050928020544f90509@mail.gmail.com> In-Reply-To: <689eb347050928020544f90509@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-09/txt/msg00228.txt.bz2 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