gdb port project

["Decker, Paul" <Paul dot Decker at analog dot com>]

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. 

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.  


Sorry for the long winded discussion, I'm really looking for your
creative ideas.


Thanks,
Paul.