Custom port questions

Custom port questions

[Jamie Guinan]

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

Re: Custom port questions

[Andrew Cagney]

> 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