This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Is multiprocessor debugging multithreaded debugging?
- From: Ramana Radhakrishnan <ramana dot radhakrishnan at codito dot com>
- To: Steven Johnson <sjohnson at sakuraindustries dot com>
- Cc: Anupama Chandwani <anupama dot chandwani at gmail dot com>, drow at false dot org, gdb at sources dot redhat dot com
- Date: Wed, 28 Sep 2005 16:41:57 +0530
- Subject: Re: Is multiprocessor debugging multithreaded debugging?
- References: <689eb347050928020544f90509@mail.gmail.com> <433A6D8B.8080605@sakuraindustries.com>
- Reply-to: 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)