This is the mail archive of the 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]

Re: Custom port questions


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,

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: 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.


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