Re: gdb port project

[Daniel Jacobowitz <drow@false.org>]

On Fri, Apr 22, 2005 at 01:30:06PM -0400, Decker, Paul wrote:
>  
> 
> 
> Hello everyone,
> 
> We've been considering a port of gdb to support a new processor.  A
> couple of implementation specific questions seem to come to mind and I
> was curious if anyone had any ideas on these:
> 
> 1.  The gdb port would consist of the gdb application and a gdb
> proxy(server) which would connect to a custom ICE.  The gdb proxy has a
> list of registers for the specific processor which are in a specific
> order.  The gdb application also will have a list of registers.  Is
> there a way to insure these register lists are in 'sync' with each
> other, for example if an older version of the gdb proxy were used with a
> newer gdb which supported more registers, or registers in a different
> order.  This question could also be extended to include a basic gdb
> connecting to a proxy which supported multiple derivatives of the same
> processor, perhaps with a different feature set.
> 
> One thought I had was to extend the gdb debugger to ask, on startup, the
> proxy how many registers it supported, what their names were, and what
> order they were in. 

GDB doesn't currently support anythin like that.  But, I think it will
soon; I have a prototype implementation which is pretty similar to what
you describe.  I just need to find the time to propose it properly.

Normally you just define a register mapping, and make sure to add new
registers at the end.

> 2.  I've searched around for multi-processing support within gdb, and I
> don't see much in the way of supporting debugging multi-processor
> systems.  Specifically, if a processor has multiple cores, is there any
> standard convention for gdb to support this?
> 
> My initial idea was to have the proxy & ice support the multi cores, and
> have the ability of two instances of gdb to be started, the first
> instance would connect over tcp to port n, the second instance would
> connect to the second core on port n+1.  This way, 1 to n multi-cores
> could be debugged and controlled.  The downside is that there are no
> native multi-processor commands in gdb, for example, a run would cause a
> specific core to start running.  There isn't a method of issuing a 'run
> all' or a 'run group' to cause all the cores to or a group of cores to
> start running.  

In general, you use a single GDB and a single stub.  You present the
multiple cores as threads of a single program.  Anything missing in GDB
for dealing with multiple cores is likely to be missing for dealing
with threads, too; the models are very similar.

-- 
Daniel Jacobowitz
CodeSourcery, LLC