Re: gdb tool for multi-proc MIPS32

[Michael Snyder <msnyder@redhat.com>]

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