This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb port project
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