gdb for multicore processors ?

gdb for multicore processors ?

[Kim Lux]

We need to port gdb to handle the Freescale (formerly Motorola)
68HC9S12X devices, which have 2 processors:  the main CPU called the
9S12 and an auxillary IO RISC processor called the XGATE processor.

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.

I'll provide more details of the processors as people need them. 

We already handle the 9S12 CPU with gdb in the 68HC9S12 devices.  (No
XGATE on them.)  

We interface to the processor via a Background Debug Pod.  The 9S12X BDM
can set breakpoints for each processor independently. 

So... how do we set GDB up to handle this ?

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 ?

The goal is to use gdb under Eclipse.  There it would be preferable to
have 2 separate instances of gdb.    


-- 
Kim Lux,  Diesel Research Inc.

Re: gdb for multicore processors ?

[Kim Lux]

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. 

Thanks in advance for your ideas. 


On Wed, 2005-12-07 at 22:47 -0700, Kim Lux wrote:
> We need to port gdb to handle the Freescale (formerly Motorola)
> 68HC9S12X devices, which have 2 processors:  the main CPU called the
> 9S12 and an auxillary IO RISC processor called the XGATE processor.
> 
> 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.
> 
> I'll provide more details of the processors as people need them. 
> 
> We already handle the 9S12 CPU with gdb in the 68HC9S12 devices.  (No
> XGATE on them.)  
> 
> We interface to the processor via a Background Debug Pod.  The 9S12X BDM
> can set breakpoints for each processor independently. 
> 
> So... how do we set GDB up to handle this ?
> 
> 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 ?
> 
> The goal is to use gdb under Eclipse.  There it would be preferable to
> have 2 separate instances of gdb.    
> 
> 
-- 
Kim Lux,  Diesel Research Inc.

Re: gdb for multicore processors ?

[Daniel Jacobowitz]

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

Re: gdb for multicore processors?

[Michael Snyder]

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.

gdb for multicore processors?

[Bridge Wu]

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