Re: MIPS: Handle the DSP registers

[Daniel Jacobowitz <drow@false.org>]

On Tue, Dec 18, 2007 at 01:41:44PM +0000, Nigel Stephens wrote:
> Sounds like this mechanism could rapidly get unwieldy if there were many
> disjoint, optional register sets supported by an architecture -- would
> you need a different description for each possible permutation? For
> example with a bare-iron target you might want to omit the
> floating-point register descriptions for CPUs which don't have a h/w
> FPU, so then we've got Base, Base+FPU, Base+DSP, Base+FPU+DSP. Then
> double again for 32-bit vs 64-bit, and so on. Or have I missed something.

You have, but it's a very small thing.

The hand-written descriptions in the GDB source code serve three
purposes.  They are used for gdbserver (which could be made smarter);
they are used for GDB (but only to eliminate the build dependency on
expat); and they are used as canonical examples for stub writers.

There's at least two ways we could support a large set of combinations
in GDB.  One is to require expat, provide XML files at the feature
level, and generate the top level target description using strcat
(one of CodeSourcery's stubs does it this way).   The other is to
adjust the precompiling process, which currently generates a callable
C function per target description, to generate functions at the
feature level and call those from within GDB.  That's a bit nicer.

Since so far we only support MIPS with an attached FPU (due to change
somewhere in MTI's GDB patch collection, I think?) there's only four
descriptions, so no one's bothered to do that flexibility yet.  But
the framework is there when we need it :-)

gdbserver is not very bright; its register set is selected entirely at
compile time and the C parts know a bit about the layout of the XML
parts.  Eventually, it's going to grow multiple description support
just like GDB, I think.  I just haven't needed it yet.

-- 
Daniel Jacobowitz
CodeSourcery