Re: Is multiprocessor debugging multithreaded debugging?

[Ramana Radhakrishnan <ramana dot radhakrishnan at codito dot com>]

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 <here> 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)