This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Custom port questions
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: guinan at bluebutton dot com
- Cc: Gdb List <gdb at sources dot redhat dot com>
- Date: Mon, 14 Apr 2003 00:48:23 -0400
- Subject: Re: Custom port questions
- References: <Pine.LNX.4.33.0303191726370.14864-100000@gemini.home.net>
Hi,
At my day job, I'm working with a custom chip with a 32-bit risc core.
It has a functional GDB port, and applications are written using a custom
assembler generating 32-bit ELF via BFD (it has a full a binutils port).
Now, I'm considering adding support for a dual-core version of the chip,
and I'm thinking about how to [re]organize the GDB implementation.
Are the ISA's related or orthogonal?
If [vaguely] related the something like sh-tdep.c is possible.
Some details on the programming model:
a) There is no ABI per-se, just .text with jumps and branches...
b) but the ELF symbol table allows us to inspect variables and
set breakpoints.
c) In the dual-core scenario, a single ELF image is shared by both
cores, so it is reasonable to set a single breakpoint and have
either core hit it.
So I am thinking about treating the two cores as "threads", and leveraging
whatever multi-{thread,cpu,context} support is in GDB. Searching the gdb
list archives, I found these postings interesting as far as indicating the
state of things,
http://sources.redhat.com/ml/gdb/2001-03/msg00122.html
http://sources.redhat.com/ml/gdb/2003-02/msg00031.html
Can anyone suggest a good existing target to study as an example, perhaps
one with a programming model similar to the one I describe above?
Unfortunatly no. None currently exist. The d10v is getting close
though. You may want to also look at:
http://sources.redhat.com/gdb/papers/multi-arch/ see: Changes for true
multi-arch.
Also, I might want to "multi-arch" the single and dual core versions in a
single GDB, as they have slightly different ISAs. I can rummage through
*-tdep.c, but if anyone thinks this-or-that chip has the best/cleanest
multi-arch support, a pointer would be appreciated.
Andrew