This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: gdb tool for multi-proc MIPS32
- From: Srinivas Murthy <codevana at gmail dot com>
- To: Michael Snyder <msnyder at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Fri, 10 Jun 2005 13:48:50 -0700
- Subject: Re: gdb tool for multi-proc MIPS32
- References: <7cb1293c05060810067a485e41@mail.gmail.com> <42A9FA20.20303@redhat.com>
- Reply-to: Srinivas Murthy <codevana at gmail dot 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.
>
>