Re: Is multiprocessor debugging multithreaded debugging?

[Steven Johnson <sjohnson@sakuraindustries.com>]

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