gdb for multicore processors?

Hello,

I want to know whether gdb support multicore debugging now.
I searched
below from this mailing list, but didn't know the current
status. Is
there any plan or roadmap to support multicore debugging?

-- 
best regards,
-Bridge

On Wed, Dec 07, 2005 at 10:49:39PM -0700, Kim Lux wrote:
> One more thing.
>
> XGate code gets compiled to reside in flash.  However,
it gets relocated
> to run from RAM as it runs much faster there.  GDB will
have to know
> that the address it sees in RAM isn't the address it
was compiled to.
> The file format is elf, if that helps.

How to handle this depends on how you do it.  Traditionally
you set the
VMA in the ELF file to point to the RAM location; then
everything will
Just Work.

> On Wed, 2005-12-07 at 22:47 -0700, Kim Lux wrote:
> > Each processor has its own register set and
instruction set.  They are
> > not the same.  They share the same memory map, but
the xgate processor
> > addresses things differently.

> > We are building the BDM, so theoretically we could
connect 2 gdb
> > processes to the same BDM, if that helps.  That
would allow us to have a
> > separate GDB instance for each process.  Or should
one GDB instance
> > handle both processors ?

I strongly recommend using two GDB sessions, for now.  It's
a long-term
design goal for GDB to be able to debug heterogenous
systems, but no
one has been working on it lately, and there's a long way to
go.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

On Fri, 2006-09-29 at 11:29 +0800, Bridge Wu wrote:
> Hello,
> 
> I want to know whether gdb support multicore debugging
now. I searched
> below from this mailing list, but didn't know the
current status. Is
> there any plan or roadmap to support multicore
debugging?

The most interesting "thread" of conversation (pun
intended) 
that I've taken part in has been with the idea that, if they

are symmetric multi-processors and if they are running the
same
code, we could somehow hoax them into the thread model. 
Treat
each core as a thread.

This could for instance be done with cooperation from the 
target side.  If gdb were talking to a remote stub or 
gdbserver, then the remote side could simply report each
core using a different "thread id", and to gdb it
would be
transparent.