gdb tool for multi-proc MIPS32

gdb tool for multi-proc MIPS32

[Srinivas Murthy]

Hi,
 We need to develop a gdb debug tool for a custom multi-processor MIPS
target running in an infinite loop (without an OS) over a serial link
with a UART. The host is an x86 machine with Linux OS.

 The single UART needs to provide connectivity to all the processors
on the target and the debug tool needs to do processor specific
commands (breakpoints, source-level debug, etc.).

 Can you guys please point me to any reference material,
implementations, etc. for me to get started with this?

Thanks much for your help.

Regards,
-Srinivas

Re: gdb tool for multi-proc MIPS32

[Michael Snyder]

Srinivas Murthy wrote:
> Hi,
>  We need to develop a gdb debug tool for a custom multi-processor MIPS
> target running in an infinite loop (without an OS) over a serial link
> with a UART. The host is an x86 machine with Linux OS.
> 
>  The single UART needs to provide connectivity to all the processors
> on the target and the debug tool needs to do processor specific
> commands (breakpoints, source-level debug, etc.).
> 
>  Can you guys please point me to any reference material,
> implementations, etc. for me to get started with this?

As far as what's in the official gdb source repository,
no one has ever done this, or anything like it.  It's
likely that someone has done it outside of official gdb,
as a research or development project, and maybe even published
their results -- I wouldn't know.

But I have a suggestion for you, assuming you are doing
SIMD or something like it (all the processors running the
same instruction image).  Pretend that your
processor cores are threads running under a single
processor.  GDB knows how to deal with that.  You must
have some sort of gdb "stub" or "agent" (like rda or
gdbserver) running on the target side -- just tell
that guy to interpret a thread id (from gdb) as a
processor id.  "Give me this thread's registers" will
be interpreted as "give me this processor's registers".
Switching thread contexts will be interpreted as
switching processor contexts.

If you're not doing SIMD (ie. if your processors may
be running completely different code images), then
you'll probably have to debug each processor under a
separate gdb session, and multiplex their communications
onto your single uart somehow.

Re: gdb tool for multi-proc MIPS32

[Srinivas Murthy]

Great suggestion.
Thanks.

I've been going over the gdb_internals doc on the web.

For the target side, what would be a good starting point for me to put
this together (for MIPS32)?

Thanks,
-Srinivas


On 6/10/05, Michael Snyder <msnyder@redhat.com> wrote:
> Srinivas Murthy wrote:
> > Hi,
> >  We need to develop a gdb debug tool for a custom multi-processor MIPS
> > target running in an infinite loop (without an OS) over a serial link
> > with a UART. The host is an x86 machine with Linux OS.
> >
> >  The single UART needs to provide connectivity to all the processors
> > on the target and the debug tool needs to do processor specific
> > commands (breakpoints, source-level debug, etc.).
> >
> >  Can you guys please point me to any reference material,
> > implementations, etc. for me to get started with this?
> 
> As far as what's in the official gdb source repository,
> no one has ever done this, or anything like it.  It's
> likely that someone has done it outside of official gdb,
> as a research or development project, and maybe even published
> their results -- I wouldn't know.
> 
> But I have a suggestion for you, assuming you are doing
> SIMD or something like it (all the processors running the
> same instruction image).  Pretend that your
> processor cores are threads running under a single
> processor.  GDB knows how to deal with that.  You must
> have some sort of gdb "stub" or "agent" (like rda or
> gdbserver) running on the target side -- just tell
> that guy to interpret a thread id (from gdb) as a
> processor id.  "Give me this thread's registers" will
> be interpreted as "give me this processor's registers".
> Switching thread contexts will be interpreted as
> switching processor contexts.
> 
> If you're not doing SIMD (ie. if your processors may
> be running completely different code images), then
> you'll probably have to debug each processor under a
> separate gdb session, and multiplex their communications
> onto your single uart somehow.
> 
>

Re: gdb tool for multi-proc MIPS32

[Michael Snyder]

Srinivas Murthy wrote:
> Great suggestion.
> Thanks.
> 
> I've been going over the gdb_internals doc on the web.
> 
> For the target side, what would be a good starting point for me to put
> this together (for MIPS32)?

Have you checked out rda?
http://sourceware.org/rda/
You can obtain the sources via anonymous cvs if you like.
Directions are on the homepage.


> On 6/10/05, Michael Snyder <msnyder@redhat.com> wrote:
> 
>>Srinivas Murthy wrote:
>>
>>>Hi,
>>> We need to develop a gdb debug tool for a custom multi-processor MIPS
>>>target running in an infinite loop (without an OS) over a serial link
>>>with a UART. The host is an x86 machine with Linux OS.
>>>
>>> The single UART needs to provide connectivity to all the processors
>>>on the target and the debug tool needs to do processor specific
>>>commands (breakpoints, source-level debug, etc.).
>>>
>>> Can you guys please point me to any reference material,
>>>implementations, etc. for me to get started with this?
>>
>>As far as what's in the official gdb source repository,
>>no one has ever done this, or anything like it.  It's
>>likely that someone has done it outside of official gdb,
>>as a research or development project, and maybe even published
>>their results -- I wouldn't know.
>>
>>But I have a suggestion for you, assuming you are doing
>>SIMD or something like it (all the processors running the
>>same instruction image).  Pretend that your
>>processor cores are threads running under a single
>>processor.  GDB knows how to deal with that.  You must
>>have some sort of gdb "stub" or "agent" (like rda or
>>gdbserver) running on the target side -- just tell
>>that guy to interpret a thread id (from gdb) as a
>>processor id.  "Give me this thread's registers" will
>>be interpreted as "give me this processor's registers".
>>Switching thread contexts will be interpreted as
>>switching processor contexts.
>>
>>If you're not doing SIMD (ie. if your processors may
>>be running completely different code images), then
>>you'll probably have to debug each processor under a
>>separate gdb session, and multiplex their communications
>>onto your single uart somehow.
>>
>>
> 
>