RE: GDB for Multiprocessor Architecture

RE: GDB for Multiprocessor Architecture

[Nitin Gupta]

> 
> Making gdb handle multiple object images will be a lot of 
> work. You can do 
> something much simpler: Use multiple gdbs.

That could be a very messy task and also in a scenario when multiple
CPUs are running same code image. Also I will have to have more than 100
GDB sessions to accomplish this. Thought about it but seems to be not a
good solution.

> 
> You'll have to implement multiplexing of serial connections 
> used by them. A 
> small program that listens to tcp/ip sockets for gdb 
> connections on one side 
> and uses the hardware probe on the other.

Well that is what I am trying to work around with. The thing is that GDB
actually needs to understand that there are number of threads running.
I plan to use the existing thread model of GDB where you do
               gdb> thr 2
to switch to another thread and do debugging on it.
In my case, I do not have a single code image or you can say a final
executable with thread information to be loaded on the target. There are
CPU specific code images. Like a DSP application has to tum on the DSP
core so it is compiled with the specific cross compiler and assembled
and linked...some management tasks are similarly compiled, assembled and
linked with CPU specific toolchain.
Now there is loader routine that loads these to specific CPUs and based
on profile information, a code image is run on n number of CPUs to get
maximum throughput.
Hereissues with GDB arises. GDB loads symbol information from a file on
the host. Now I do not have just single code image. Can I change and
load the symbol table as and when I want? I can add symbol table for
library files but am not sure about altogether different image file.

Any pointers? Thanks in advance.

Nitin Gupta

RE: GDB for Multiprocessor Architecture

[Nitin Gupta]

> CPU's can be modeled using GDB's thread framework.  However, 
> at present 
> the model doesn't extend as far as modeling separate memory 
> regions for 
> each CPU (something that needs to be fixed).
> 
I need this feature for my model and I am ready to enhance this feature
in GDB.
However, I have some queries. GDB remote protocol does not have a field
that can tell me about the processor (thread) id. This means that can I
on-the-fly switch from one thread to another? I feel this has to be
incorporated in the protocol. Hence it will be comething like every
message actually coming with the processor id attached with it.
I plan to extend the GDB remote protocol and make changes in remote.c
file. Roghly how big this enhancemet will be?
Has anybody done work on this earlier? Where can I find some more
documents on the remote protocol. The code obviously is the best doc.

Nitin Gupta

Re: GDB for Multiprocessor Architecture

[Daniel Jacobowitz]

On Fri, Dec 05, 2003 at 02:35:47AM +0530, Nitin Gupta wrote:
> 
> > CPU's can be modeled using GDB's thread framework.  However, 
> > at present 
> > the model doesn't extend as far as modeling separate memory 
> > regions for 
> > each CPU (something that needs to be fixed).
> > 
> I need this feature for my model and I am ready to enhance this feature
> in GDB.
> However, I have some queries. GDB remote protocol does not have a field
> that can tell me about the processor (thread) id. This means that can I
> on-the-fly switch from one thread to another? I feel this has to be
> incorporated in the protocol. Hence it will be comething like every
> message actually coming with the processor id attached with it.
> I plan to extend the GDB remote protocol and make changes in remote.c
> file. Roghly how big this enhancemet will be?
> Has anybody done work on this earlier? Where can I find some more
> documents on the remote protocol. The code obviously is the best doc.

Take a look at the existing thread specification packets in the remote
protocol.  It is documented in the GDB manual, available online or in
Texinfo format in the source tree.  You want the Appendix named Remote
Serial Protocol.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

GDB for Multiprocessor Architecture

[Nitin Gupta]

Hi,
How can GDB be used to debug an application running on a chip that has n
number of similar CPUs. These CPUs share memories and run different code
images.
I plan to do a debugging session using the hardware probe and the GDB
remote protocol. My target does not have any OS support as Linux or
RTEMS but the host is a Linux box.
My question is how can I get to know that currently GDB is talking to
which CPU? Is it possible for me to do something like 
gdb> load image1.o
gdb> CPU=1
gdb> |get register contents|
gdb> load image2.o
gdb> CPU=3
gdb> |get register contents|

and such similar stuff.

One way of implementing this is using the thread model but then each CPU
has altogether different code image to execute. Shall I have multiple
sessions of GDB, one per CPU? But again if a debug exception is raised
say a breakpoint is hit, how will I know on the host side which CPU has
hit the breakpoint.

Has anybody done a similar task on any other target? Any help on this
fron shall be grateful.

Thanks and Regards
Nitin

Re: GDB for Multiprocessor Architecture

[Andrew Cagney]

> Hi,
> How can GDB be used to debug an application running on a chip that has n
> number of similar CPUs. These CPUs share memories and run different code
> images.
> I plan to do a debugging session using the hardware probe and the GDB
> remote protocol. My target does not have any OS support as Linux or
> RTEMS but the host is a Linux box.
> My question is how can I get to know that currently GDB is talking to
> which CPU? Is it possible for me to do something like 
> gdb> load image1.o
> gdb> CPU=1
> gdb> |get register contents|
> gdb> load image2.o
> gdb> CPU=3
> gdb> |get register contents|
> 
> and such similar stuff.
> 
> One way of implementing this is using the thread model but then each CPU
> has altogether different code image to execute. Shall I have multiple
> sessions of GDB, one per CPU? But again if a debug exception is raised
> say a breakpoint is hit, how will I know on the host side which CPU has
> hit the breakpoint.
> 
> Has anybody done a similar task on any other target? Any help on this
> fron shall be grateful.

CPU's can be modeled using GDB's thread framework.  However, at present 
the model doesn't extend as far as modeling separate memory regions for 
each CPU (something that needs to be fixed).

Andrew

Re: GDB for Multiprocessor Architecture

[Amit S. Kale]

Hi,

Making gdb handle multiple object images will be a lot of work. You can do 
something much simpler: Use multiple gdbs.

You'll have to implement multiplexing of serial connections used by them. A 
small program that listens to tcp/ip sockets for gdb connections on one side 
and uses the hardware probe on the other.
-- 
Amit Kale
EmSysSoft (http://www.emsyssoft.com/)
KGDB: Linux Kernel Source Level Debugger (http://kgdb.sourceforge.net)

On Wednesday 03 Dec 2003 11:58 pm, Andrew Cagney wrote:
> > Hi,
> > How can GDB be used to debug an application running on a chip that has n
> > number of similar CPUs. These CPUs share memories and run different code
> > images.
> > I plan to do a debugging session using the hardware probe and the GDB
> > remote protocol. My target does not have any OS support as Linux or
> > RTEMS but the host is a Linux box.
> > My question is how can I get to know that currently GDB is talking to
> > which CPU? Is it possible for me to do something like
> > gdb> load image1.o
> > gdb> CPU=1
> > gdb> |get register contents|
> > gdb> load image2.o
> > gdb> CPU=3
> > gdb> |get register contents|
> >
> > and such similar stuff.
> >
> > One way of implementing this is using the thread model but then each CPU
> > has altogether different code image to execute. Shall I have multiple
> > sessions of GDB, one per CPU? But again if a debug exception is raised
> > say a breakpoint is hit, how will I know on the host side which CPU has
> > hit the breakpoint.
> >
> > Has anybody done a similar task on any other target? Any help on this
> > fron shall be grateful.
>
> CPU's can be modeled using GDB's thread framework.  However, at present
> the model doesn't extend as far as modeling separate memory regions for
> each CPU (something that needs to be fixed).
>
> Andrew

Re: GDB for Multiprocessor Architecture

[Mark]

If these CPUs share the same memories and run the same code image but different data, how about gdb does one-for-multithread debugging ? Shall I have multiple sessions of GDB, one per CPU? 

Mark
Thanks in advance

----- Original Message ----- 
From: "Andrew Cagney" <cagney@gnu.org>
To: "Nitin Gupta" <nitin.gupta@nevisnetworks.com>
Cc: "Daniel Jacobowitz" <drow@mvista.com>; "Ian Lance Taylor" <ian@wasabisystems.com>; <gdb@sources.redhat.com>
Sent: Thursday, December 04, 2003 2:28 AM
Subject: Re: GDB for Multiprocessor Architecture


> > Hi,
> > How can GDB be used to debug an application running on a chip that has n
> > number of similar CPUs. These CPUs share memories and run different code
> > images.
> > I plan to do a debugging session using the hardware probe and the GDB
> > remote protocol. My target does not have any OS support as Linux or
> > RTEMS but the host is a Linux box.
> > My question is how can I get to know that currently GDB is talking to
> > which CPU? Is it possible for me to do something like 
> > gdb> load image1.o
> > gdb> CPU=1
> > gdb> |get register contents|
> > gdb> load image2.o
> > gdb> CPU=3
> > gdb> |get register contents|
> > 
> > and such similar stuff.
> > 
> > One way of implementing this is using the thread model but then each CPU
> > has altogether different code image to execute. Shall I have multiple
> > sessions of GDB, one per CPU? But again if a debug exception is raised
> > say a breakpoint is hit, how will I know on the host side which CPU has
> > hit the breakpoint.
> > 
> > Has anybody done a similar task on any other target? Any help on this
> > fron shall be grateful.
> 
> CPU's can be modeled using GDB's thread framework.  However, at present 
> the model doesn't extend as far as modeling separate memory regions for 
> each CPU (something that needs to be fixed).
> 
> Andrew
> 
> 
> 
> 
>