Re: gdb tool for multi-proc MIPS32

[Srinivas Murthy <codevana@gmail.com>]

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.
> 
>