This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Custom port questions


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.

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?

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.

Thanks,
-Jamie


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]